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PREFACE 


This  system  requirement  document  covers  the  work  performed 
under  Air  Foroe  Contract  F33615-80-C-5155  (ICAM  Project  6201). 
This  contract  is  sponsored  by  the  Materials  Laboratory,  Air 
Force  Systems  Command,  Wright-Pat terson  Air  Foroe  Base,  Ohio. 

It  was  administered  under  the  technical  direction  of  Mr.  Gerald 
C.  Shumaker,  ICAM  Program  Manager,  Manufacturing  Technology 
Division,  through  Project  Manager,  Mr.  David  Judson.  The  Prime 
Contractor  was  Production  Resources  Consulting  of  the  General 
Electric  Company,  Scheneotady,  Mew  Tork,  under  the  direction  of 
Mr.  Alan  Rubenstein.  The  General  Eleotric  Project  Manager  was 
Mr.  Myron  Hurlbut  of  Industrial  Automation  Systems  Department, 
Albany,  New  Tork. 

Certain  work  aimed  at  improving  Test  Bed  Technology  has 
been  performed  by  other  contracts  with  Project  6201  performing 
integrating  functions.  This  work  consisted  of  enhancements  to 
Test  Bed  software  and  establishment  and  operation  of  Test  Bed 
hardware  and  communications  for  developers  and  other  users. 
Documentation  relating  to  the  Test  Bed  from  all  of  these 
contractors  and  projects  have  been  integrated  under  Project  6201 
for  publication  and  treatment  as  an  integrated  set  of  documents. 
The  particular  contributors  to  each  document  are  noted  on  the 
Report  Documentation  Page  (DD1473).  A  listing  and  description 
of  the  entire  project  documentation  system  and  how  they  are 
related  is  contained  in  document  FTR620100001 ,  Project  Overview. 

The  subcontractors  and  their  contributing  activities  were 
as  follows: 


TASK  4.2 


Subcontractors 

Boeing  Military  Aircraft 
Company  ( BMAC ) 

D.  Appleton  Company 
(DACOM) 


General  Dynamics/ 
Ft.  Worth 


Role 

Reviewer . 


Responsible  for  IDEF  support, 
state-of-the-art  literature 
search. 

Responsible  for  factory  view 
function  and  information 
models . 
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Subcontractors 

Illinois  Institute  of 
Technology 

North  American  Rockwell 
Northrop  Corporation 

Pritsker  and  Associates 
SofTech 


Role 

Responsible  for  factory  view 
function  research  (IITRI) 
and  information  models  of 
small  and  medium-si se  business. 

Reviewer. 

Responsible  for  factory  view 
function  and  information 
models. 

Responsible  for  IDEF2  support. 
Responsible  for  IDEFO  support. 


TASKS  4.3  -  4.9  (TEST  BED) 

Subcontractors  Role 

Boeing  Military  Aircraft  Responsible  for  consultation  on 

Company  ( BMAC )  applications  of  the  technology 

and  on  IBM  computer  technology. 


Computer  Technology 
Associates  (CTA) 


Assisted  in  the  areas  of 
communications  systems,  system 
design  and  integration 
methodology,  and  design  of  the 
Network  Transaction  Manager. 


Control  Data  Corporation  Responsible  for  the  Common  Data 
(CDC)  Model  (CDM)  implementation  and 

part  of  the  CDM  design  (shared 
with  DACOM). 


D.  Appleton  Company  Responsible  for  the  overall  CDM 

(DACOM)  Subsystem  design  integration 

and  test  plan,  as  well  as  part 
of  the  design  of  the  CDM 
(shared  with  CDC).  DACOM  also 
developed  the  Integration 
Methodology  and  did  the  schema 
mappings  for  the  Application 
Subsystems . 


SRD620 140000 

1  Vovember  1985 

Subcontractors 

Role 

Digital  Equipment 
Corporation  (DEC) 

Consulting  and  support  of  the 
performance  testing  and  on  DEC 
software  and  computer  systems 
operation. 

McDonnell  Douglas 
Automation  Company 
(McAuto) 

Responsible  for  the  support  and 
enhancements  to  the  Network 
Transaction  Manager  Subsystem 
during  1984/1985  period. 

On-Line  Software 
International  (OSI) 

Responsible  for  programming  the 
Communications  Subsystem  on  the 
IBM  and  for  consulting  on  the 
IBM. 

Rath  and  Strong  Systems 
Products  CRSSP)  (In  1985 
became  McCormack  9  Dodge) 

Responsible  for  assistance  in 
the  implementation  and  use  of 
the  MRP  II  package  (PIOS)  that 
they  supplied. 

SofTech ,  Inc . 

Responsible  for  the  design  and 
implementation  of  the  Network 
Transaction  Manager  (NTM)  in 
1981/1984  period. 

Software  Performance 
Engineering  (SPE) 

Responsible  for  directing  the 
work  on  performance  evaluation 
and  analysis. 

Structural  Dynamics 
Research  Corporation 
(SDRC) 

Responsible  for  the  User 
Interface  and  Virtual  Terminal 
Interface  Subsystems . 

Other  prime  contractors  under  other  projects  who  have 
contributed  to  Test  Bed  Technology,  their  contributing 
activities  and  responsible  projects  are  as  follows: 

Contractors  ICAM 

Project  Contributing  Activities 

Boeing  Military 
Aircraft  Company 
( BMAC ) 


Enhancements  for  IBM 
node  use.  Technology 
Transfer  to  Integrated 
Sheet  Metal  Center 
(ISMC) . 


1701.  2201, 
2202 
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Contractors 

I CAM  Project 

Contributing  Activities 

Control  Data 
Corporation  (CDC) 

1502,  1701 

IISS  enhancements  to 
Common  Data  Model 
Processor  (CDMP). 

D.  Appleton  Company 
(DACOM) 

1502 

IISS  enhancements  to 
Integration  Methodology. 

General  Electric 

1502 

Operation  of  the  Test 
Bed  and  communi cat ions 
equipment . 

Hughes  Airoraft 

Company  (HAC) 

1701 

Test  Bed  enhancements. 

Structural  Dynamics 
Research  Corporation 
(SDRC) 

1502,  1701, 
1703 

IISS  enhancements  to 
User  Interface/Virtual 
Terminal  Interface 
(DI/VTI). 

Systran 

1502 

Test  Bed  enhancements. 
Operation  of  Test  Bed. 
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FOREWORD 


Revision  A  of  this  System  Requirements  Document  (SRD)  has 
been  done  at  the  end  of  the  teohnioal  work  in  order  to  more 
accurately  reflect  the  system  that  was  actually  developed.  The 
primary  revisions  are  to  add  indications  of  the  level  to  which 
listed  requirements  were  satisfied  by  the  system  a6  implemented 
in  Release  2.0,  the  last  release  of  the  contract.  Requirements 
that  were  not  addressed  are  listed  as  “(Future)”,  and  in  many 
oases  a  “(Partial)”,  or  further  explanation,  is  appended  to 
requirements  that  were  not  addressed  as  fully  as  had  been 
envisioned  at  the  time  the  requirements  were  specified. 

The  fact  that  a  requirement,  constraint,  or  function  is 
listed  as  “Future”  does  not  imply  that  it  should  definitely  be 
done  in  the  future,  as  there  are  many  functions,  for  example, 
that  were  not  done  because  further  design  work  revealed  problems 
and  reasons  why  they  should  possibly  not  be  done  at  all.  This 
further  reasoning  is  left  to  other  more  detailed  project 
documents.  Further,  the  fact  that  a  function  is  not  qualified 
does  not  mean  that  there  is  not  more  that  could  be  done  in  the 
function  in  future  work,  it  only  implies  that  the  functionality 
provided  was  reasonable  considering  the  expectations  when  the 
requirments  were  developed. 

It  was  also  felt  that  this  document  would  be  of  more  value 
to  future  developers  to  essentially  leave  it  in  its  original 
state  with  annotations  of  what  was  accomplished  in  order  to 
preserve  the  thinking  that  was  considered  and  developed,  rather 
than  completely  revising  it  to  an  "As-Built”  SRD. 
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SECTION  1 

INTRODUCTION  AMD  SYSTEM  OVERVIEW 


1 • 1  Background 

The  objective  of  this  projeot  is  to  establish  and  operate  a 
Test  Bed  to  validate  the  concept  of  Integrated  Applications 
supported  by  an  Integrated  Information  Support  Systen  (IISS). 

In  addition,  the  project  is  to  establish  a  set  of  interim 
standards  2nd  procedures  to  guide  the  design  of  the  IISS  and  to 
provide  guidance  to  other  I CAM  projects.  Finally,  a  set  of 
requirements  is  to  be  established  which  will  be  the  basis  for 
enhancements  to  the  IISS. 

This  project  is  intended  to  provide  the  test  and 
demonstration  vehicle  for  the  I CAM  Information  Support  System 
concepts  described  in  the  30  September  1981  “Integrated  Sheet 
Metal  Center"  (Threads  Document)  and  the  Project  Priority  3101 
Computer  Based  Information  System  (CBIS)  Requirements  Document. 
As  the  strategy  for  evolution  to  the  "CBIS  data  Class  II"*  and 
"CBIS  data  Class  I"*  environments  is  developed  and  implemented, 
the  associated  costs  and  benefits  can  be  tracked  against  the 
baseline  system. 

The  ICAM  products  being  considered  by  the  Project  Priority 
2201/2  contractors  for  implementation  in  the  Integrated  Sheet 
Metal  Center  (ISMC)  can  be  implemented  first  on  the  Test  Bed. 

In  this  process,  the  problems  of  rehosting  the  software, 
integrating  multiple  ICAM  products,  and  demonstrating 
performance  will  be  identified  and  solved,  thus  reducing  the 
risk  to  the  ISMC  implementator.  Cost  and  performance 
evaluations  of  the  products  can  be  done  within  the  Test  Bed. 


*Four  data  classes  are  defined  as  follows: 

Class  I  -  data  totally  managed  by  CBIS 

Class  II  -  data  directly  accessed  by  CBIS,  but  externally 
managed 

Class  III  -  data  subject  to  CBIS  standards  and  procedures 
Class  IV  -  data  subject  to  CBIS  guidelines 

A  fifth  class,  defined  as  "private  data,"  is  totally  outside  of 
the  control  of  the  CBIS  policies  and  procedures. 


1-1 


SRD620 140000 
1  Hovember  1985 


I CAM  products  not  chosen  for  implementation  in  the  ISMC 
can  also  be  installed  on  the  Test  Bed.  providing  the  sane 
evaluation  benefits  and  reduction  of  risk  to  other  potential 
users . 

1.1.1  Relationship  of  the  Test  Bed  to  Other  I CAM  Projects 

The  first  Test  Bed  demonstration  (early  1983)  is  to  include 
the  shop  floor  control  system  from  Project  Priority  6103 
(Manufacturing  Control  Material  Management  -  MCMM).  integrated 
with  appropriate  modules  of  a  commercially  available 
Manufacturing  Resource  Planning  (MRP)  system.  This  integration 
will  be  supported  by  appropriate  tools  from  the  Integrated 
Decision  Support  System  (IDSS)  similar  in  capability  to  the 
"mid-configuration*'  described  in  the  ICAM  Program  Office's  30 
September  1981  ISMC  "Threads  Document." 

The  contents  of  the  subsequent  demonstrations  after  early 
1983  will  depend  on  several  factors  and  come  from  several 
sources.  For  example,  they  oould  come  from 

requirements /recommendations  from  within  this  Test  Bed  project, 
from  the  ICAM  Program  Office,  from  other  ICAM  Projects 
(particularly  ISMC  Projects  2201/2),  and  from  industry  in 
general.  Enhanced  capabilities  in  the  manufacturing  systems 
applications  area  (technical  and  control  threads)  will  come 
mainly  from  Project  5501  (IPS)  and  the  Integrated  Decision 
Support  Systems  (IDSS)  Projects  8203  and  8205.  System 
Engineering  Methodology  (SEM)  tools  will  come  from  SEM  Project 
1701 . 


The  Test  Bed  project  has  worked  and  will  continue  to  work 
closely  with  other  related  ICAM  projects  in  determining  system 
requirements,  defining  standards  and  procedures  for  the  initial 
implementation,  and  identifying  deficiencies  and  voids  in  the 
available  components.  Beyond  the  functional  and  application 
areas,  methods  to  be  used  in  all  aspects  of  the  system  life 
cycle  are  also  to  be  addressed.  Aspects  to  be  coordinated  with 
the  SEM  (System  Enginering  Methodology  -  ICAM  Project  Priority 
1701)  include:  data  definition  methods;  database  design;  use  of 
the  data  dictionary;  structured  analysis  methods;  system 
specification  techniques;  prototype  development;  standards  for 
data  definition;  data  manipulation;  message  definition;  and 
documentation  standards  and  performance  analysis  techniques. 

Meeds  and  priorities  for  enhancements  will  be  defined  by 
the  ICAM  Program  Office  based  on  recommendations  from  the  Test 
Bed  project  coalition  and  related  projects.  Requirements  for 
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the  enhancements  will  be  defined  by  this  Project  (6201). 
Project  Priority  1701M  (SEM)  will  have  the  responsibility  for 
designing  and  building  the  required  software  and  defining  the 
required  standards,  procedures,  and  guidelines  based  on  the 
requirements.  To  facilitate  the  coordination  of  this  Project 
6201  with  Project  1701,  a  formal  working  arrangement  has  been 
established  with  the  Project  1701  Prime  Contractor. 


1.1.2  Strategy  for  Evolution 


It  has  been  estimated  that  in  large  U.S.  corporations,  most 
of  the  existing  computer  applications  will  be  redesigned  over 
the  next  10  to  20  years.  It  is  further  expected  that,  due  to 
the  rapidly  changing  computer  technology,  the  construction 
techniques  and  operation  modes  of  new  applications  will  bear 
little  resemblenoe  to  those  of  existing  systems. 


The  Project  Priority  3101  CBIS  coalition  provided  a  set  of 
six  principles  as  guides  in  formulating  a  solution  for  the 
(relatively)  near  term  which  are  also  extensible  for  the 
expected  long  term  trends.  Individually,  each  of  these 
principles  reflects  state-of-the-art  technology;  however,  they 
have  not  been  implemented  together  to  yield  an  integrated 
system.  These  principles  are  stated  as  follows: 


1.  IISS  is  a  key  mechanism  for  the  integration  of 

computerized  manufactur ing .  It  defines,  controls,  and 
executes  actions  affecting  information  among  various 
functionally  independent  subsystems,  based  on  the  use 
of  common  data. 


2.  IISS  employs  a  coordinated  databat e  approach  to  support 
information  resource  management  of  various  application 
systems  in  a  closed  loop  environment  within 
manufactur i ng . 


3.  IISS  implementation  strategy  employs  several  stages  of 
data  and  application  control  which  allow  for  increased 
usage  of  facilities  as  management  seeks  to  gain  greater 
benefits  from  the  IISS. 


4.  IISS  operates  as  a  transaction  oriented  system 
responding  interactively  to  user  commands,  rather  than 
to  prescheduled  batches  of  computer  programs. 

5.  IISS  is  accessible  from  geographically  dispersed 
locations . 
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These  principles  and  other  results  of  the  CBIS  project  have 
been  taken  as  a  starting  point  and  extended  and  further 
articulated  by  the  ICAM  Program  Office  and  the  Project  6201 
coalition.  Requirements,  specifications,  and  the  overall  system 
design  are  being  developed  with  a  view  of  both  short  and 
long-term  implementation  plans  for  the  Test  Bed. 

The  “cost  drivers"  which  the  ICAM  CBIS  Requirements 
Definition  (Project  Priority  5101)  defined  as  critically 
associated  with  the  CBIS  environment  are  summarized  in  the 
following  nine  categories,  all  of  which  are  being  considered  as 
part  of  the  Test  Bed  IISS  design: 

1.  Data  independence  -  making  computer  data  files 
independent  of  the  programs  which  use  them. 

2.  Data  nonredundancy  -  minimizing  the  number  of 
occurrences  of  the  same  data  in  different  files. 

3.  Data  relatability  -  facilitating  the  changing  of  file 
structure  based  on  specific  "views"  required  by 
different  programs  and  transactions. 

4.  Data  integrity  -  improving  data  quality,  consistency, 
and  recoverability. 

5.  Data  accessibility  -  providing  low-cost,  user-friendly 
access  to  data  stored  in  various  files  and  computers. 

6.  Data  shareability  -  ensuring  that  many  programs  can 
access  the  same  files  simultaneously  without  degrading 
performance . 

7.  Data  security  -  ensuring  that  data  are  isolated  from 
users  who  should  not  have  access  to  it. 

8.  Data  performance  -  providing  proper  controls  for 
changing  the  CBIS  environment  over  time  as  changing 
user  needs  cause  the  basic  system  requirements  to 
change . 

9.  Data  administration  -  supplying  appropriate  standards, 
procedures,  and  guidelines  to  ensure  consistent 
evolution  of  the  CBIS  environment  as  demands  and 
techno 1 og i es  change . 
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Implied  above  is  the  need  for  the  IISS  to  operate  in  a 
mixed  environment  containing  old  and  newly  developed 
applications.  It  is  clearly  recognised  that  the  existing 
applications  mu6t  be  supported,  while  techniques  for  technology 
development  and  new  applications  development  are  concurrently 
provided. 

1 .2  Summary  of  Expected  Benefits  of  the  Test  Bed  and  IISS 

The  Test  Bed  will  serve  as  a  step  toward  realising  the  full 
benefits  of  a  CBIS  as  represented  by  the  "cost  drivers”  in  the 
preceding  section  (Section  1.1.2).  It  will  also  serve  as  a 
facility  to  assist  others  to  achieve  these  benefits  faster  and 
with  less  risk.  Some  of  the  benefits  of  the  Test  Bed  may  be 
summarised  as  follows: 

1.  Provide  testing  facility  for  individual  I CAM  software 
products . 

2.  Demonstrate  initial  integration  of  ICAM  products. 

•  Data  integration  via  the  Common  Data  Model 

•  Techniques  and  procedures  for  more  extensive 
integration  of  program  functions 

3.  Provide  a  site  for  demonstration  and  evaluation  of  ICAM 
products . 

•  Applications 

•  Methodologies 

•  Information  support  system 

4.  Reduce  risk  to  subsequent  users  of  ICAM  products. 

5.  Provide  standards,  guidelines,  and  procedures. 

•  For  development  of  ICAM  products 

•  For  evaluation/adoption  by  industry 

6.  Demonstrate  strategy  for  transition  from  current 
application  processing  and  development  methods  to  use 
of  the  evolving  techniques  which  will  subsequently 
reduce  cost  and  increase  system  flexibility. 
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•  Distributed  heterogeneous  systems,  distributed  dat&, 
and  distributed  processing. 

e  Independence  of  application  data  f roa  considerations 
of  actual  internal  storage  organisation  and  database 
Management  System  access  techniques. 

e  Reduced  data  redundancy . 

e  Automated  data  validation  and  constraint  check i ng 
through  the  Common  Data  Model . 

e  Transaction-oriented  applications. 

•  Standardized  User  Interface  (similar  menu 
construction  for  all  applications,  standard  user 
‘‘HELP"  procedures,  standard  error  messages,  etc.). 

e  Control  of  execution,  in  a  consistent  manner,  of 
processes  on  different  computers  using  different 
operating  systems. 

•  Facilitate  and  control  passing  of  data  and  messages 
between  processes  on  the  same  or  different 
computers . 

•  Consistent  error  handling  throughout  the  system. 

•  System-wide  control  of  startup,  shutdown,  restart, 
and  recovery. 

•  Application  programs  written  using  relational 
database  languages  referencing  nonrelational 
databases . 

•  Independence  of  application  program  from  the 
computer  on  which  the  user  terminal  is  located. 

•  Independence  of  application  program  from  the 
characteristics  of  the  terminal  on  which  it  will  be 
used. 

•  System- supported  translation  of  information  formats 
to  host-specific  representations. 
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1.5  Test  Bed  System  Overview 

The  following  is  an  overview  of  the  presently  envisioned 
Hardware  and  Software  Architecture. 

1.5.1  Hardware  Architecture 


The  hardware  architecture  of  the  Test  Bed  supports  the 
interconnection  of  the  heterogeneous  computer  systems  required 
to  demonstrate  the  functionality  of  the  Test  Bed  (Figure  1-1). 

The  Test  Bed  hardware  architecture  supports  the 
interconnection  of  three  computer  systems  via  a  Local  Area 
Network  (LAN)  complemented  by  Wide  Area  Communication  Services. 

The  three  computers  embedded  in  the  Test  Bed  are: 

1.  A  Honeywell  Level  6  computer  supporting  the  MCMM 
database  and  MCMM  application  programs. 

2.  A  VAX  11/780  computer  or  equivalent  supporting: 

•  Test  Bed  User  Interface 

•  Test  Bed  Common  Data  Model 

•  IDSS  2.0  and  its  database 

3.  An  IBM  3033  computer  supporting  an  MRP  package  to  be 
selected  in  conjunction  with  the  IPS  Project  Priority 
5501  team. 

The  Test  Bed  makes  use  of  a  Local  Area  Network  to 
interconnect  the  Honeywell  Level  6  and  the  VAX  11/780  which  are 
in  close  geographical  proximity.  This  approach  offers  high 
throughput,  ease  of  installation,  expansion  capabilities,  and 
supports  the  process-to-process  communication  capabilities 
required  to  integrate  the  heterogeneous  databases  present  in  the 
Test  Bed  environment. 

The  Test  Bed  makes  use  of  Wide  Area  Communication  lines  to 
extend  the  functionality  and  usefulness  of  the  Test  Bed  to 
computers  which  are  remote  geographical ly . 

1.  A  synchronous  leased  line  provides  medium  speed 

communication  capabilities  to  the  General  Electric 
owned  IBM  3033  located  3.5  miles  away  from  the 


Figure  1-1.  Interconnection  of  Heterogeneous  Sy6teas  Via 
Local  Area  Network 
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oomputer  center  used  to  develop  the  Test  Bed. 

2.  Asynchronous  lines  are  provided  to  interconnect  the 

I CAM  (CIDS)  and  ISMC  development  computers  to  the  Local 
Area  Network  hardware,  as  well  as  to  interconnect  ISMC 
development  terminals  to  the  VAX  11/780  of  the  Te6t  Bed 
through  the  User  Interface. 

The  Test  Bed  hardware  architecture  allows  for  expansibility 
and  flexibility. 

1.  The  Test  Bed  hardware  architecture  can  be  expanded  to 
the  MAX  Configuration  described  in  the  Threads 
Document.  Back  end  data  machines  and/or  additional 
general  purpose  computers  can  be  interconnected  via  the 
Local  Area  Network. 

2.  The  Test  Bed  hardware  architecture  can  be  expanded  to  a 
full  size  production  system  with  minimal  changes  to  the 
software . 

1.3.2  Software  Architecture 

The  major  software  subsystems  are  also  indicated  in  Figure 

1-1 . 

1.3. 2.1  Distributed  Application  Data  on  Heterogeneous  Databases 

The  application  data  are  distributed  in  heterogeneous 
database  management  systems,  themselves  resident  in 
heterogeneous  processors.  This  approach  allows  for  the 
integrated  query  of  existing  databases  by  new  integrated 
applications  without  conversion  of  the  database. 

1 . 3 . 2 . 2  Class  II  Data  Integration 

The  Test  Bed  software  and  system  utilities  support  Class  II 
(see  footnote,  page  1-1)  data  inquiries.  These  inquiries  may  be 
directed  toward  any  database  resident  in  the  Test  Bed,  and  are 
under  the  direct  control  of  the  Test  Bed  Common  Data  Model 
Processor.  System  utilities  perform  data  integrity  checks 
selectively  on  the  data  being  retrieved  in  the  system.  The 
early  1983  implementation  of  the  Test  Bed  supports  updates  on 
the  databases  bound  to  the  Application  Subsystems.  Update 
activities  are  under  the  control  of  the  Application  Subsystems 
and  are  under  indirect  control  of  the  CDM  to  the  extent  that 
data  entry  and  messages  are  checked  by  the  CDM.  The  data 
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Integrity  checks  performed  include  edit,  domain,  and  range 
ohecking.  The  data  required  to  support  the  data  integrity 
checks  are  contained  in  the  Common  Data  Model,  and  is  under 
control  of  the  Common  Data  Model  Administrator.  Data  inquiries 
use  the  Test  Bed  Heutral  Data  Manipulation  Language  to  query 
Common  Data  contained  in  the  databases  integrated  by  the  Test 
Bed.  The  Test  Bed  Meutral  Data  Manipulation  Language  allows  the 
definition  of  nonprocedural  queries  which  are  independent  of  the 
structure  of  the  database(s)  being  accessed.  System  services 
allow  the  retrieval  of  data  contained  in  more  than  one  database 
in  more  than  one  system. 

1.3. 2. 5  Pser  Interface  and  Data  Query  via  Preplanned 
Transactions 


In  the  early  1983  implementation,  Pser  Interface  and  data 
query  are  accomplished  by  preplanned  transactions  and  messages. 
This  method  will  evolve  toward  ad-hoc  inquiries  as  development 
of  the  Test  Bed  continues  after  early  1983.  Information  queries 
via  preplanned  transactions  support  the  manufacturing  scenarios 
which  have  been  identified  and  constitute  a  natural  first  step 
toward  ad-hoc  query.  Message  integrity  checking  is  supported  by 
system  functions,  and  is  performed  selectively.  The  information 
required  to  support  the  message  integrity  checks  is  contained  in 
the  Common  Data  Model  and  is  under  the  control  of  the  Common 
Data  Model  Administrator.  (Message  integrity  checking  -  Future) 

1.3. 2. 4  Integration  and  Coordination  Through  the  Common  Data 
Model 


The  Common  Data  Model  is  a  resouroe  which  is  maintained  in 
a  centralized  fashion  to  support  the  following  functions: 

•  Define  logical  structure  of  the  information  common  to 
two  or  more  Application  Subsystems.  The  definition 
includes  entities,  their  attributes,  and  the 
relationships  between  entities. 

•  Define  the  domain  and  values  of  the  entities. 

•  Access  control  or  authorization  information  identifying 
the  operations  that  can  be  accessed  by  a  particular 
user.  (Future) 


•  Define  the  format  of  the  data  as  stored. 

•  Catalog  of  Common  database  procedures  such  as  schema 
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translation,  scheaa  definition.  Neutral  Data 
Manipulation  Language  statement  translation,  and  data 
translation  procedures. 

e  Locate  the  specified  data  in  the  logical  data  structure 
(Test  Bed  Conceptual  Scheaa) . 

e  Convert  query  requests  to  fit  the  locations  of  the  data 
and  the  required  processing. 

e  Aggregate  the  responses  from  the  various  databases . 

e  Check  for  the  validity  and  completeness  of  update 
requests  (Class  II  environment).  (Future) 

e  Support  the  user  interface. 

1 . 3 . 2 . 5  Integration  and  Coordination  Through  the  Integrated 
Network  Transaction  Manager 

The  Common  Data  Model  provides  a  repository  for  the  data 
describing  the  data,  procedures,  and  policies  which  are  shared 
between  the  various  IISS  Application  Subsystems. 

The  Network  Transaction  Manager  provides  the  operational 
implementation  of  the  above  concepts,  the  control  of  the 
execution  of  transactions,  the  control  of  the  flow  of  messages 
through  the  network,  the  restart  and  recovery  requirements,  and 
the  monitoring  of  perf ormance . 

The  Network  Transaction  Manager  is  invoked  to  carry  out  the 
following  functions: 

•  Dispatch  of  messages  through  the  IISS  Network 

•  Follow-up  on  open  transactions 

•  Logging,  time  stamping  of  messages 

•  Monitoring  of  system  performance  (Future) 

•  System  synchronization 

•  Restart  of  the  IISS  system 

•  Restart  and  recovery  of  the  databases  (Future) 
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•  Control  of  Application  Subsystems 

The  Network  Transaction  Manager  controls  the  execution  of 
application  subsystems  by  processing  the  Transaction  Message 
queues  built  on  each  node.  The  queues  provide  the  necessary 
buffering  action  resulting  from  the  asynchronous  nature  of  the 
Test  Bed  Application  Subsystem. 

1.5. 2. 6  Guaranteed  Delivery  of  Messages 

The  Network  Transaction  Manager  is  also  invoked  to 
guarantee  the  delivery  of  messages.  This  service  is  provided  to 
facilitate  the  migration  of  the  Test  Bed  to  the  Class  I 
environment . 

This  capability  guarantees  that  messages  will  be  delivered, 
even  if  the  destination  application  subsystem  is  temporarily 
unavailable.  To  that  effect,  the  messages  are  uniquely 
identified  at  the  level  of  the  IISS  by  journalizing 
the  message  type  and  Application  Subsystem  of  origin,  and  by 
time  stamping.  Time  stamping  and  journalizing  allow  for  the 
chronological  reconstruction  of  the  transaction  input  stream. 
This  technique  supports  the  recovery  of  unavailable  nodes  or 
Application  Processes. 

It  should  be  further  noted  that  the  system  can  guarantee 
that  the  message  was  given  to  the  destination  process,  and  even 
that  the  process  acknowledged  having  completed  processing.  The 
system  cannot,  however,  guarantee  that  the  receiving  process 
actually  did  process  the  message  and  perform  the  requested 
functions,  or,  for  that  matter,  that  the  message  was  even  read. 
The  proper  processing  of  messages  is  totally  dependent  on  the 
receiving  application  process  and  cannot  be  controlled  or 
guaranteed  by  the  IISS  system. 

1.3. 2. 7  Standard  User  Interface 
Test  Bed  User  Interface 


A  Test  Bed  User  Command  Language  simplifies  the  task  of  the 
user  when  interacting  with  the  Test  Bed.  User  inputs  are 
through  a  forms  system  including  menus,  formatted  data  displays, 
and  forms  for  data  entry.  The  inputs  are  then  formulated  into 
standard  messages  that  are  6ent  to  the  application  processes  in 
the  proper  host  computer. 

The  User  Interface  thus  provides  a  unified  format  to  invoke 
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Test  Bed  System  Utilities  as  well  as  to  support  the  user 
dialogues  of  Application  Subsystems  specifically  designed  for 
the  Test  Bed. 

Virtual  Terminal 

The  proliferation  of  terminal  hardware  and  the  wide 
disparity  in  capabilities  and  features  of  commercially  available 
terainals  create  an  interfacing  problea  between  IISS  and  its 
terainals . 

This  problea  is  resolved  by  defining  a  specific  set  of 
terainal  features  and  protocols  which  aust  be  supported  by  the 
IISS  software.  This  set  of  features  and  protocols  constitutes 
the  IISS  virtual  terainal  definition. 

Specific  terainals  are  then  napped  against  the  IISS  virtual 
terainal  software  by  specific  software  nodules  written  for  each 
type  of  real  terainal  interfaced  to  IISS.  This  approach  is 
consistent  with  the  layered  software  philosophy  of  IISS  since  it 
peraits  the  interfacing  of  a  wide  variety  of  terainals  without 
changes  to  the  IISS  application  prograns. 

System-Wide  Fores  and  Protocols 

User  foras  and  user  protocols  are  defined  at  the  IISS 
systea  level.  These  foras  and  protocols  define  the  aanner  in 
which  the  IISS  user  interfaces  with  IISS.  The  foras  are  data 
structures  with  attributes  which  are  enforced  by  the  foras 
package.  Mandatory  fields,  alphanuneric  fields,  and  nuaeric 
only  fields  are  exanples  of  the  attributes  which  are  enforced  by 
the  foras  package. 

The  foras  and  protocols  are  defined  by  data  stored  in  the 
CDM,  and  as  such  are  very  flexible  and  extensible. 

1 .4  Terns  and  Abbreviations 

Active :  Coaputer  enforced  (at  compile  time  or  at  run  time). 

Activity  Framing :  Feature  which  allows  to  declare  a  set  of 
Application  Processes  as  being  part  of  a  single  operation  which 
makes  sense  from  the  user  viewpoint.  All  database  changes 
contained  within  an  activity  frame  are  incorporated  or  else  none 
are  incorporated  in  the  databases . 

Appl i cat ion  Process :  A  cohesive  unit  of  software  that  can  be 
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initiated  as  a  unit  to  perforn  sone  function  or  functions. 

Application  Process  Cluster:  An  Application  Process  Cluster  is 
the  logical  grouping  of  Application  Processes  and  of  one  Message 
Processing  Unit  (MPO)  HTM  component. 

Application  Subsystem:  An  Application  Subsystem  is  composed  of 
one  or  more  application  processes  and  performs  specific 
manufacturing  management  functions.  Instances  of  I CAM 
Application  Subsystems  are:  MCMM,  XDSS,  and  a  commercially 
available  MRP  System. 

Class  II  Data:  Data  for  which  query  activity  is  under  direct 
control  of  the  IISS  and  for  which  update  activity  is  under 
indirect  control  of  the  IISS. 

Common  Data 

1.  Data  used  by  more  than  one  application  Subsystem. 

2.  Data  updated  by  one  Application  Subsystem  and  used  by 
another . 

3.  Data  planned  to  evolve  into  a  category  described  by  (1) 
or  ( 2 )  above . 

Common  Data  Model :  Describes  common  data  application  process 
formats,  screen  definitions,  etc.  of  the  IISS  and  includes 
conceptual  schema,  external  schemas,  internal  schemas,  and 
schema  transformation  operators. 

Data  Integrity:  Improved  data  quality,  consistency  and 
recoverability.  The  Test  Bed  common  data  is  subject  to  the 
following  integrity  checks: 

1 .  Type  checking 

2.  Existence  checking 

3.  Edit  checking  (7  digit  telephone  number) 

4.  Attribute  value  checking  (shirtsize  -  small,  medium, 
large) 

5.  Range  checking 

Deadlock :  Two  processes  are  said  to  be  dead  locked  when  each 
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process  is  waiting  on  the  other  to  complete  before  proceeding. 

Domain  Check;  Operation  which  ensures  that  the  values  of  a 
given  attribute  lie  within  some  prescribed  set  of  values.  These 
values  nay  be  continuous,  discrete,  numeric  or  non-nuaeric. 

Expert /Novice  Mode:  The  User  Interface  supports  the  concept  of 
Expert/Movice  aode  of  user  interaction.  In  the  novice  aode,  the 
user  receives  tutorial  assistance  froa  the  systea  to  guide  his 
selection  of  systea  features  and  functions.  In  the  expert  aode, 
the  tiae  consuaing  tutorial  assistance  is  suppressed  for  aaxiaua 
efficiency. 

Fora:  Predefined  screen  foraat  description.  The  description 
includes  the  textual,  cursor  positioning,  data  checking 
inforaation  required  to  display  or  input  data  into  IISS. 

Guaranteed  Del ivery:  Test  Bed  provided  service  which  ensures 
the  delivery  of  a  aessage  to  its  destination  even  if  the 
destination  process  is  unavailable  at  the  tiae  the  aessage  is 
issued. 

Integrated  (Test  Bed)  Application  Process ;  An  Application 
Process  which: 

1.  Uses  the  Neutral  Data  Manipulation  Language  to  retrieve 
Class  II  data  which  nay  be  distributed  on  several 
databases  resident  on  the  Test  Bed. 

2.  By  the  end  of  the  contract,  it  uses  the  local  database 
manipulation  language  to  update  the  local  database  to 
which  it  is  bound. 

3.  Performs  its  terminal  Input/Output  operations  on  the 
Test  Bed  terminals. 

4.  Is  controlled  from  the  Test  Bed  terminals. 

Mon-Integrated  (Test  Bed)  Application  Process :  An  Application 
Prooess  which: 

1.  Does  not  use  the  Neutral  Data  Manipulation  Language  to 
retrieve  Class  II  data.  The  local  database  Management 
System  data  manipulation  language  is  used  for  local 
database  manipulation  (update,  retrieval). 

2.  Performs  its  terminal  Input /Output  operations  on  the 
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Test  Bed  terminals. 


9.  Is  controlled  from  the  Test  Bed  terainals. 

Mon  Procedural  Query:  Value  stated  query.  The  query  stateaent 
focuses  on  what  needs  to  be  retrieved  rather  than  on  how  to 
carry  out  the  retrieval  operations. 

Paired  Message:  A  message  which  oontains  either  one  of  the 
following: 

a.  A  request  for  a  reply 
or 

b.  A  reply  to  a  uniquely  identified  request. 

Pre-def ined  Query  Application  Processes :  Inforaation  processing 
functions  iapleaenting  predefined  data  query  application 
processes.  The  code  required  for  iapleaentation  is  predefined 
(annually  if  necessary)  precoapiled  and  linked. 

Response  Tiae:  Duration  of  wall  clock  tiae  between  subnission 
of  a  user  request  and  receipt  of  the  first  character  of  output. 

Synchronization  Point:  Quiet  point  where  the  following  is  true: 

1.  The  Test  Bed  databases  are  in  a  consistent  state 

2.  The  state  of  the  queues  of  pending  application  process 
is  known  and  available  for  future  reference 

3.  The  state  of  the  databases  is  known  and  available  for 
future  reference 

4.  The  state  of  the  queues  of  pending  application  process 
and  the  state  of  the  databases  have  been  given  a  common 
identifier . 


System  Clean 

1 .  The 

2.  The 

3.  The 
and 


Point :  State  of  the  system  which  satisfies  to: 

Test  Bed  databases  are  in  a  consistent  state. 

state  of  the  databases  is  known  and  available. 

state  of  the  queues  of  pending  messages  is  known 
avai lable . 
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System  Quiet  Point:  Period  of  time  during  which  the  following 
is  true: 

1.  The  dispatch  of  messages  triggering  the  execution  of 
application  processes  i6  suspended. 

2.  All  dispatched  application  processes  are  closed 
(processing  is  completed). 

3.  System  quiet  points  are  Invoked  and  terminated  under 
control  of  the  Test  Bed  operator  or  Test  Bed  control 
mechanism . 

Terminal  Control  Words:  A  neutral  representation  of  terminal 
features  implemented  by  specific  control  characters. 

Test  Bed  Oti 1 ities :  Test  Bed  functions  that  either  provide  Test 
Bed  operability  or  facilitate  the  execution  and  terminal 
input/output  operations  of  the  Application  Processes  resident  on 
the  Test  Bed. 

Time  to  Complete:  Duration  of  wall  clock  time  between 
submission  and  completion  of  a  user  request. 

Oser  Interface  :  Test  Bed  services  which  facilitate  the  man 
machine  dialogs  between  the  Test  Bed  services,  some  of  the 
Integrated  or  Non- Integrated  Application  Process  resident  on  the 
Test  Bed  and  the  Test  Bed  user.  The  User  Interface  services  are 
available  through  the  Test  Bed  terminals. 
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SECTION  2 

TEST  BED  SYSTEM  REQUIREMENTS  DOCUMENT 


2.1  Scope 

2.1.1  Identification 


This  document  defines  the  concepts,  objectives,  functions, 
and  other  requi resents  for  the  I CAM  Integrated  Information 
Support  System  (IISS)  Test  Bed.  This  system  is  intended  to  be  a 
test  computing  environment  providing  integrated  data  management 
facilities  and  distributed  processing  for  heterogeneous 
databases  resident  on  heterogeneous  computer  systems 
interconnected  via  a  Local  Area  Network. 

This  document  has  been  prepared  by  Project  Priority  6201  of 
the  Air  Force's  I CAM  Program.  This  project  is  being  conducted 
by  the  General  Electric  Company,  with  the  participation  of 
SofTech,  Inc.  and  of  Control  Data  Corporation,  supported  by 
various  consultants  and  contributors. 

This  project  is  sponsored  by  the  Manufacturing  Technology 
Division  of  the  Air  Force  Wright  Aeronautical  Laboratories. 

2.1.2  Background 

The  requirements  stated  herein  are  derived  from  many 
sources,  including  ICAM  subsystems  documents,  state-of-the-art 
technical  publication  and  the  authors'  experience  in  the 
development  of  computer  systems.  The  CBIS  state-of-the-art. 
Environment ,  System  Requirement  Documents ,  and  the  various 
documents  transmitted  by  the  ICAM  Program  Office  to  the  General 
Electric  Company  are  central  to  the  establishment  of  the  present 
document.  These  documents  are  referenced  in  Section  2.2.  This 
document  states  the  requirements  which  must  be  met  by  the  Test 
Bed. 


2.1.3  Functional  Description 

This  document  is  written  to  provide: 

1.  System  Requirements  that  must  be  satisfied  by  the  IISS 
Test  Bed.  These  requirements  are  stated  to  serve  as  a 
basis  for  mutual  understanding  between  the  users,  ICAM 
Program  Office  personnel.  General  Electric  and  the 
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devel opaent  subcontractors . 

2.  A  basis  for  systea  design. 

3.  A  basis  for  systea  test. 

4.  Traceability  between  systea  requireaents  and  systea 
needs  as  expressed  in  various  Air  Force  docuaents. 

2 . 2  References 


2.2.1  Applicable  Docuaents 

Systran,  Inc..  I CAM  Docuaen tat i on  Standards,  ICAM  Docuaent 
IDS  1S0120000A.  28  Deo  81. 

A.D.  Little,  ICAM  Coaputer  Based  Inforaatlon  Systea 
CCBIS) .  Systea  Envlronaent  Docuaent,  ICAM  Docuaent  SED 
310140000.  Sept  81. 

A.D.  Little,  ICAM  Coaputer  Based  Inforaatlon  Systea 
(CBIS) .  State  of  the  Art  Docuaent .  ICAM  Docuaent  SAD 
310140000.  Sept  81. 

A.D.  Little,  ICAM  Coaputer  Based  Inforaatlon  Systea 
(CBIS) .  Systea  Recrulreaent  Docuaent,  ICAM  Docuaent  SRD 
310140000.  Sept  81. 

ICAM  Prograa  Office,  The  Integrated  Sheet  Metal  Center .  30 
Sept  81 . 

N.  Tupper,  Meaorandua  for  the  Record ,  5  Oct  81. 

2.2.2  Terns  and  Abbreviations 

See  Section  1.4  of  this  docuaent. 

2.3  Requireaents 

2.3.1  Specific  Requireaents 

2. 3. 1.1  Specific  Requireaents  and  Constraint  Suaaary 

Functional  requireaents  for  the  IISS  Test  Bed  are  derived 
fron  a  needs  analysis  attached  to  this  docuaent  as  Appendix  A. 


Table  2-1  is  a  succinct  list  of  these  requireaents. 
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TABLE  2-1 

FUNCTIONAL  REQUIREMENTS 


I 


FUNCTIONS 


HEEDS 


R1 


Provide  Data  Shareability  Between 
Integrated  and  Non- Integrated  Application 
Subsystems 


I  Needs  A. 3.1 


R2 

i  Provide  Common  User  Interface  to 

l  Meeds  A. 3.7 

i  Integrated  and  Non- Integrated 

i  Applications  Subsystems 

1 

1 

1 

l 

I  Needs  A. 3. 11 

I 

l  Meeds  A . 3 . 3 

R3 

I  Measure  and  Report  System  Performance 

1 

R4 

l  Provide  Test  Bed  System  Control 

I 

l  Needs  A. 3. 6 

R5 

i  Maintain  Test  Bed  System  Control 

1  Engineering 

l  Information 

1 

l  Judgment 

1 

R6 

i  Provide  Capability  to  Implement  and  Test 

I  Engineering 

I  Programs  on  Test  Bed 

l  Judgment 

1  SYSTEM  CONSTRAINTS 

l  NEEDS 

SCI 

1  General  System  Constraints 

I 

i 

I 

I  Needs  A. 3. 12 

1  Needs  A. 4.1 

I  Needs  A . 4 . 2 
l  Needs  A . 5 . 0 

Notation: 

1.  Each  requirement  is  identified  by  a  unique  requirement 
number  (Example  R3). 

2.  Each  system  constraint  number  is  uniquely  identified 
by  a  unique  system  constraint  number  (Example  SCI). 

3.  Each  constraint  is  uniquely  identified  by  its 
constraint  number  within  the  scope  of  the  requirement 
to  which  it  applies  (Example  C3.2). 

4.  The  above  table  cross  references  Requirements  and 
System  Constraints  to  the  Specific  Needs  shown  in 
Appendix  A,  or  to  accepted  Engineering  principles. 
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Table  2-2  lists  all  constraints  bearing  on  the 
requirements  identified  in  Table  2-1.  The  remainder  of  this 
subsection  is  a  description  of  the  requirements  and  constraints 
identified  in  Table  2-1  and  2-2. 


TABLE  2-2 

Rl:  DATA  SHAREABILITT  BETWEEN  INTEGRATED  AND 
NON- INTEGRATED  APPLICATION  SUBSYSTEMS 


I  CONSTRAINTS 


I  NEEDS 


1 

PERFORMANCE 

C.1.0 

1 

■ 

Query  Capabilities 

C.l. 01 

1 

1 

1 

Dead  Lock  Resolution 

1 

1 

PHYSICAL 

C.1.1 

1 

Heterogeneous  Computer  Systems 

C.l. 2 

1 

Heterogeneous  Database  Managers 

C.l. 3 

1 

CODAS YL  Databases 

Engineering 

Judgment 

Engineering 

Judgment 

Needs  A . 3 . 5 . 1 
Needs  A. 3. 4.1 
Needs  A. 3. 4. 2 


C.l  .4 

C.1.5 


TEST 

Traceable  Messages 
DESIGN 

Query  Transactions 


C.l. 5.1 
C.l. 6 
C.  1 .7 


Integrated  Application  Processes 
Migration  to  Class  I  Integration 
Class  II  Data  Integrity  Checking 


C.l. 7.1 


Message  Integrity  Checking 


C.1.8 


C.l. 9 


C.l. 10 
C.l. 11 
C.l. 12 
C.  1 . 13 


Minimize  Modifications  to  Host 
Operating  Systems 
Minimize  Modifications  to  Existing 
Application  Systems 
Transparent  Data  Location 
Transaction  Processing 
Prioritized  Transaction  Processing 
Predefined  Transaction  Messages 
(Early  Implementation) 

Active  Data  Security 


Engineering 

Judgment 

Engineering 
Judgment 
Needs  A. 3. 9.1 
CBIS  A. 2. 6. 4 
Engineering 
Judgment 
Engineering 
Judgment 
Engineering 
Judgment 
Engineering 
Judgment 
Needs  A. 3. 6. 3 
Needs  A. 3. 9. 3 
Needs  A. 3. 9. 4 
Engineering 
Judgment 
Needs  A. 3. 3.7 


C.l. 14 
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TABLE  2-2  (Cont'd) 

R2 :  PROVIDE  COMMON  USER  INTERFACE  TO  INTEGRATED  AND 
MON-INTEGRATED  APPLICATION  SUBSYSTEMS 


I 


CONSTRAINTS 


I  NEEDS 


I  PHYSICAL 

I  - 

C.2.0  i  Single  Terninal  Interface 
I 

C.2.1  I  Virtual  Terninal  Interface 
l 

I  DESIGN 


Engineering 
Judgaent 
Needs  A. 4. 2. 4 


C.2.2 


C.2.3 


C.2.4 


C.2.5 

C.2.6 

C.2.7 

C.2.8 


Consistent  Invocation  and  Control 
of  Application  Subsystens 
Invocation  and  Control  of 
Test  Bed  Utilities 
Extensibility,  Flexibility  of 
User  Interface 

Application  Subsystens  Security 
Centralised  User  Interface  Support  Data 
Forns  Generator 
Report  Generator 


Needs  A. 3. 7.1 

Needs  A. 3. 7. 4 

Needs  A. 3. 7. 2 

Needs  A. 3.6. 2 
Needs  A. 3. 6. 8 
Needs  A. 3. 7. 3 
Needs  A. 3. 7. 3 


R3 :  MEASURE  AND  REPORT  SYSTEM  PERFORMANCE 


I  CONSTRAINTS  I  NEEDS 


C.3.1 

C.3.2 

C.3.3 

C.3.4 

C.3.5 


PERFORMANCE  I 

Measure  Elapsed  Tine  and  Response  Time  l 
Within  the  Tine  Resolution  of  the  Host l 
Operating  Systens  I 

Measure  Transaction  Frequency,  l 

Elapsed  Tine,  Response  Tine,  and  l 

Provide  Selective  Reporting  l 

Measure  Test  Bed  Resource  Usage  and  I 
Provide  Selective  Reporting  I 

Use  vendor  Supported  Resource  Monitors  l 

Support  User  Accountability  l 


Engineering 

Judgaent 

Needs  A . 3 . 1 1 


Needs  A. 3. 11 

Engineering 

Judgaent 
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TABLE  2-2  (Confd) 

R4 :  PROVIDE  TEST  BED  SYSTEM  CONTROL 


1 

CONSTRAINTS 

1  NEEDS 

C.4.1 

1 

Provide  Communication  Between 

l  Engineering 

1 

Application  Processes 

I  Judgment 

C.4.2 

1 

Provide  Active  Routine  of  Transaction 

I  Needs  A. 3.6. 5 

1 

Messages 

I 

C.4.3 

1 

Control  Execution  of  Application 

i  Engineering 

1 

Processes 

I  Judgment 

C.4.4 

1 

Provide  Error  Processing 

I  Engineering 

1 

l  Judgment 

C.4.5 

1 

Maintain  Test  Bed  Operability 

1  Needs  A. 3.6.1 

C.4.6 

1 

Support  Test  Bed  Recovery 

i  Needs  A. 3. 4. 3 

C.4.7 

1 

Provide  Message  Guaranteed  Delivery 

I  USAF  Verbal 

1 

Service 

I  Request 

R5 

MAINTAIN  TEST  BED  SYSTEM  CONTROL  INFORMATION 

1 

CONSTRAINTS 

1  NEEDS 

1 

PHYSICAL 

C.5.1 

1 

1 

Centralized  System  and  Common 

1 

Data  Control 

CBIS  A. 1.4 

C.5.2 

1 

1 

Controlled  Access  of  System  and  Common 
Data  Control  Information 

CBIS  A. 1.13 

C.  5 . 3 

1 

Flexibility  of  the  Common  Data  Control 

Engineering 

1 

Structure 

Judgment 

C.5.4 

1 

Test  Bed  System  Control  Migration 

Needs  A. 4. 2. 5 

C.5.5 

1 

The  Maintenance  of  the  Test  Bed  Control 

Engineering 

1 

1 

1 

Information  Is  Computer  Assisted 

DESIGN 

Judgment 

C.5.6 

1 

1 

A  Common  Data  Model  Supports 

1 

1 

the  System  and 

Common  Data  Control  Information 

CBIS  A. 1.1 

C.5.7 

1 

1 

Selective  Access  to  the  Maintenance 
Functions 

Engineering 
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TABLE  2-2  (Cont'd) 


R6:  PROVIDE  CAPABILITY  TO  IMPLEMEBT  ABD  TEST  PROGRAMS  OB  TEST  BED 


C.6.1 

C.6.2 


Protect  System  from  Mew  Application 
Programs 

Provide  Real  Data  for  Testing 


C.6.3 

C.6.4 


Make  Maximum  Use  of  Vendor  Supplied 
Utilities 

Allow  Analysis  of  Message  Journals 


C.6.5 

C.6.6 


Test  Bed  May  Be  Shut  Down  for  Special 
Conditions 

Test  Bed  Shall  Be  Accessible 


C.6.7 


Tests  Shall  Be  Repeatable 


Engineering 

Judgment 

Engineering 

Judgment 

Engineering 

Judgment 

Engineering 

Judgment 

Engineering 

Judgment 

Engineering 

Judgment 

Engineering 

Judgment 


C.6.8 


Test  Protection  Modes  Shall  Be  Easily 
Changeable 


Engineering 

Judgment 
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TABLE  2-2  (Cont'd) 


I  GENERAL  SYSTEM  OOMSTRAZMTS  I  MEEDS 


1 

I 

a 

PERFORMANCE 

1 

1 

SC1.1 

1 

i 

Engineering  Trade-offs  Consider 

1 

l  Engineering 

i 

Impacts  on  Performance 

I  Judgment 

SCI.  2 

i 

Test  Bed  Design  Is  Expansible 

i  Meeds  A . 3 . 5 . 5 

SCI.  3 

i 

Test  Bed  Performance  Improvements 

I  Engineering 

1 

1 

i  Judgment 

1 

i 

1 

PHYSICAL 

l 

SCI.  4 

i 

Heterogeneous  Hardware  Environment 

1 

I  Hardware 

i 

l  Availability 

SCI.  5 

i 

Geographic  Constraint 

l  Hardware 

• 

1  Availability 

SCI  .6 

» 

Local  Area  Network  Requirements 

I  Meeds  A. 3. 5. 3 

i 

l  Needs  A . 3 . 5 . 4 

i 

I  Needs  A . 3 . 5 . 5 

SCI  .7 

i 

Heterogeneous  Database  Management 

l  Availability 

i 

Systems 

I  Engineering 

SCI.  8 

i 

Test  Bed  Terminals 

i  Engineering 

i 

l  Judgment 

SCI  .9 

i 

Technology  Transfer  by  1  Feb  83 

1  Needs  A . 5 . 1 

SCI . 10 

i 

Test  Bed  Hardware  Is  Expansible 

I  Engineering 

1 

| 

1  Judgment 

1 

i 

TEST 

l 

SCI. 11 

1 

i 

Test  Configuration 

1 

I  Engineering 

i 

I  Judgment 

SCI. 12 

i 

Modular  Testing,  Phased  Integration 

I  Engineering 

i 

l  Judgment 

SCI .13 

i 

Demonstration  Class  II  Integration 

I 

SCI .14 

i 

MC-MM,  IDSS  2.0,  and  MRP  Demonstration  I  Needs  A. 5. 2 

i 

I  USAF  Verbal 

i 

I  Request 

SCI .15 

i 

MRP  Selection  Criterion 

l  USAF  Verbal 

i 

I  Request 

SRD620 140000 
1  November  1985 


TABLE  2-2  (Cont'd) 


i 

l 


1 

GENERAL  SYSTEM  CONSTRAINTS 

1 

NEEDS 

1 

1 

DESIGN 

1 

SCI . 16 

1 

The  System  and  Common  Data  Control 

1 

1 

Engineering 

1 

Promotes  Integration  Through  Sharable 

1 

Judgment 

1 

databases 

l 

SCI . 17 

1 

The  Test  Bed  Architecture  Is  Layered 

l 

Needs  A. 3. 12. 

1 

and  Modular 

I 

Needs  A. 3. 12. 

1 

I 

Needs  A . 4 . 1 . 5 

SCI. 18 

1 

The  Test  Bed  Software  Adheres  to  the 

I 

Engineering 

1 

Test  Bed  Standard  Guidelines  and 

I 

Judgment 

1 

Procedures 

l 

SCI . 19 

1 

The  Test  Bed  Software  Is  Extensible 

l 

CBIS  B . 3 

1 

and  Flexible 

I 

SCI .20 

1 

Physical  and  Logical  Data  Structures 

I 

Needs  A . 4 . 2 . 1 

1 

Are  Decoupled 

l 

SCI. 21 

1 

The  Test  Bed  Software  Is  Portable 

l 

Needs  A. 3. 3. 2 

SCI . 22 

1 

Binary  Data  Transfer 

I 

Needs  A. 3. 2. 4 

» 

I 

1 
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Table  2-8 

SYSTEM  REQUIREMENT  DOCUMEMT  AMD 
MEEDS  ANALYSIS  CROSS  REFERENCE  TABLE 


MEEDS  STATEMENT 

A.S.O  Test  Bed  NEEDS 

A. 3.1  Integration  Needs 

A. 3. 1.1  Integration  Denonstrati on  Needs 
A. 3. 1.2  Integration  Definition 
A. 3. 1.3  Integration  Scope 
A. 3. 1.4  Excessive  Data  Redundancy 

A. 3. 2  Interfacing  Meeds 

A. 3. 2.1  Interfacing  Stand  Alone 
CADMCAM  Systems 

A. 3. 2. 2  Interfacing  Standards 
A. 3. 2. 3  Interface  to  Process  Planning 
A. 3. 2. 4  Machine  to  Machine  Interface 
Problems 

A. 3. 3  Data  Management  Meeds 

A. 3. 3.1  Data  Structuring  Meeds 
A. 3. 3. 2  Data  Portability  Meeds 
A. 3. 3. 3  Data  Validation  Heeds 
A. 3. 3.4  Data  Integrity  Needs 
A. 3. 3. 5  Data  Redundancy  Elimination 
Meeds 

A. 3. 3. 6  Time  Dependency  of  Data  Needs 

A. 3. 3. 7  Data  Security  Meeds 

A. 3. 3. 8  Active  Data  Dictionary  Meeds 

A. 3.4  Distributed  Database  Needs 

A. 3. 4.1  Distributed  Database  Needs 
A. 3. 4. 2  database  Codasyl 

Compatibility  Needs 
A. 3. 4. 3  Individual  Database  Recovery 
and  Backup  Needs 

A. 3. 5  Heterogeneous  Hardware  Needs 

A. 3. 5.1  Multiprocessors  Heterogeneous 
Hardware  Needs 


SRD  LIME  ITEM 


R1 

SCI . 13 
Glossary 


SCI .21 


R5 

C5.6 

Cl. 7,  Cl. 7.1 
Cl. 7.  Cl. 7.1 
Consequence  of 
C5.6 

Cl.  14 


Cl  .2 

Cl  .3 
C4.6 


Cl.l 
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Table  2-5 

SYSTEM  REQUIREMENT  DOCUMENT  AMD 
MEEDS  ANALYSIS  CROSS  REFERENCE  TABLE  (Coni' d) 


NEEDS  STATEMENT 


A. 3. 5. 2  Back  End  Database  Maehine 
Meeds 

A.S.5.5  Local  Area  Network  Needs 
A. 3. 5. 4  Local  Area  MetworK 

Standardization  and  Planning 
Needs 

A. 3. 5. 5  Local  Area  Network 
Expansibility  Needs 

A. 3. 6  Common  Data  Control  Needs 

A. 3.6.1  System  Usable  Directory  of 

Network  Character istios  Needs 
A. 3. 6. 2  System  Usable  Security 
Directory  Need 

A. 3.6. 3  System  Usable  Location 
Directory  Needs 

A. 3. 6. 4  Comprehensive  Data  Dictionary 
Needs 

A. 3.6. 5  Active  Data  Dictionary  Needs 
A. 3. 6. 6  ISMC  Common  Data  Needs  (Min) 

A. 3.6.7  Common  Data  Definition  Needs 
A. 3. 6. 8  ISMC  Common  Data  Needs  (Max) 

A. 3.6.9  ISMC  Improved  Constraint 

Checking  of  Common  Data  (Max) 

A. 3. 7  User  Interface  Needs 

A. 3. 7.1  User  Interface  Consistency 
Needs 

A. 3. 7. 2  User  Interface  Flexibility 
Needs 

A. 3. 7. 3  Standard  Query/Report 
Generator  Needs  (Min) 

A. 3. 7. 4  User  Command  Language  Needs 
(Mid  82) 

A. 3.7. 5  Standard  User  Interface  Needs 
(Mid) 

A. 3. 7. 6  User  Ad-Hoc  Queries  Needs  (Min) 


SRD  LINE  ITEM 


C5.4 
SCI  .6 
SCI. 6 


SCI.  2 


R5 

C5.1 

C2.5 

Cl. 10;  C4.2 


Glossary 
C2.6 
Cl.  5 


R2 

C2.2 


C2.4 


C2.7;  C2.8 


C2.3 


C2.2 
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Table  2-5 

SYSTEM  REQUIREMENT  DOCOMEMT  AMD 
MEEDS  ANALYSIS  CROSS  REFERENCE  TABLE  (Coni' d) 


MEED8  STATEMENT 

1  8RD  LIME  ITEM 

A. 3. 8  Sinulation  Meeds 

1 

1 

A. 3. 8.1 

Manufacturing  Planning 

I  Provided  by 

Sinulation  Meeds 

I  IDSS  2.0  (Not 

A. 3. 8. 2 

Master  Sohedule  Planning 

l  Test  Bed  Re- 

Sinulation  Meeds 

l  quirenent) 

A. 3. 8. 3 

Sinulation  Batch-Run  Needs 

l 

A. 3. 8. 4 

Sinulation  Inplenentation 

I 

Needs:  IDSS 

I 

1 

A. 3. 9  Processing  Meeds 

1 

l 

A. 3. 9.1 

database  Updating  Meeds  (Min) 

l - 

A. 3. 9. 2 

database  Updating  Meeds  (Mid) 

1  — — 

A. 3.9. 3 

Transaction  and  Batch 

1  Cl. 11 

Processing  Meeds  (Min) 

1 

A. 3. 9. 4 

Transaction  Prioritisation 

1  Cl. 12 

Needs 

1 

A. 3. 9. 5 

Processor  Load  Leveling 

1 - 

Needs  (Max) 

1 

A. 3. 10  Response  Tine  Needs 

A. 3. 10.1  Imnediate  Retrieval  of 

Engineering  Changes  Needs 
A. 3. 10.2  Eight  Hour  Retrieval  of 

Engineering  Change  Preparation 
Data 


Not  Applicable 
to  Denonstrati on 
Test  Bed 


A. 3. 11  Test  Bed  Resource  Usage  Statistics 
Needs 


R3 


A. 3. 12  Test  Bed  Standards  and  Procedures 
Needs 

A. 3. 12.1  Test  Bed  Developnent  Standard 
Needs 

A. 3. 12.2  Test  Bed  Application  Standard 
Needs 

A. 3. 12.3  Test  Bed  Layering  Standard 
Needs 


SCI .18 
SCI.  18 
SCI .1? 
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Table  2-3 


SYSTEM  REQUIREMENT  DOCUMENT  AND 
NEEDS  ANALYSIS  CROSS  REFERENCE  TABLE  (Coat'd) 


NEEDS  STATEMENT 
A. 4.0  PROJECT  DRIVERS 


SRD  LINE  ITEM 


A. 4.1  Responsiveness  to  Change  Needs  i  SCI. 19 

A. 4. 1.1  Responsiveness  to  Changes  I 

in  Application  Needs  I 

A. 4. 1.2  Responsiveness  to  Changes  in  I  Cl. 5 

Data  Needs  I 

A. 4. 1.3  Responsiveness  to  Changes  in  l  SCI. 19 

Equipment  and  Technology  Needs  I 
A. 4. 1.4  Responsiveness  to  New  Data  l  SCI. 19 

Processing  Technology  Needs  I 
A. 4. 1.5  Layered  Architecture  Needs  i  SCI. 17 


A. 4. 2  Portability  Meeds 

A. 4. 2.1  Decoupling  Logical  and  Physical 
Data  Structures  Needs 
A. 4. 2. 2  Eliminating  Program  Dependency 
on  Peripherals  Needs 
A. 4. 2. 3  Eliminating  Dependency  on 
Vendor  Data  Systems  Needs 
A. 4. 2. 4  Virtual  Terminal  Needs  (Mid) 

A. 4. 2. 5  Migrating  IISS  Dictionary  to 
Back  End  Processor  Needs 


SCI. 20 


C2.1 

C5.4 


A. 4. 3  Technology  Development  Needs 

A. 4. 3.1  Systematic  Development  of 

Integration  Technology  Needs 
A. 4. 3. 2  Evolutionary  Technology 
Development  Needs 


Project  Manage¬ 
ment  Not  System 
Requirement 


A. 5.0  PROJECT  MANAGEMENT  NEEDS 


A. 5.1 

Schedule  Needs 

l 

1  SCI. 9 

A. 5. 2 

Test  Bed  Configuration  Needs: 

MRP  and  IDSS 

1  SCI. 14;  SCI. 15 

1 

A. 5. 3 

Test  Bed  Expected  Life  Needs 

1  Project  Manage- 

A. 5. 4 

Project  Traceability  Needs 

I  ment  Not  System 

A. 5. 5 

Test  Bed  Affordability  Needs 

l  Requirement 

A. 5.6 

Technology  Transfer  Needs 

l  SCI. 9 
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The  above  Needs  Analysis  cross  reference  table  show  the 
relationship  existing  between  the  statements  of  Needs  taken  from 
the  Needs  Analysis  Document  and  the  Requirements,  Constraints 
and  System  Constraints  shown  in  the  System  Requirement  Document 
(SRD) . 

m 

2. 5. 1.2  Cross  Reference  of  Needs  and  Requirements 

This  subsection  contains  a  cross  reference  of  the  Test  Bed 
needs  (see  Appendix  A)  and  of  the  specific  requirements  and 
constraints  identified  in  Section  2. 3. 1.1.  The  cross  reference 
list  is  given  in  Table  2-3. 

2. 3. 1.3  Specific  Requirement  and  Constraint  Statements 

This  subsection  contain  a  description  of  the  specific 
requirements  and  constraints  identified  in  Section  2. 3. 1.1. 

•  (Rl)  REQUIREMENT  1:  Provide  data  shareability  between 
integrated  and  non- integrated  Application  Subsystems. 

Description:  The  Test  Bed  provides  the  integration 
environment  for  integrated  and  non- integrated 
Application  Subsystems.  In  this  environment,  data  items 
which  are  used  by  more  than  one  Application  Subsystem 
may  be  shared.  Access  to  common  data  is  performed  via 
Test  Bed  system  services. 

Requirement  1  is  subject  to  the  following  constraints: 
PERFORMANCE 

C1.0  -  Query  Capabilities 

Relational  database  oriented  (one  or  more  records  rather 
than  one  record  at  a  time)  query  capabilities  are 
provided  to  support  new  applications  specifically 
designed  to  be  integrated  on  the  Test  Bed. 

Cl. 0.1  -  Deadlock  Resolution 

The  Test  Bed  resolves  Application  Subsystem  deadlocks 
over  shared  system  resources.  (Future) 

PHYSICAL  CONSTRAINTS 

Cl . 1  -  Heterogeneous  Computer  Systems 

The  Test  Bed  is  implemented  by  interconnecting  several 

distinct  and  dissimilar  computer  systems,  each  running 
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under  commercially  available  operating  systen. 

Cl . 2  -  Heterogeneous  Database  Managers 
The  application  subsysteas  integrated  by  the  test  bed 
are  supported  by  coaaercially  available  database 
aanageaent  systeas.  Since  the  application  subsysteas 
already  exist,  these  database  aanageaent  systeas  are,  in 
general,  dissiailar. 

Cl. 3  -  Databases  Structures 

1.  The  database  aanagers  which  support  the  application 
subsysteas  to  be  integrated  by  the  test  bed  are 
coapatible  with  CODASYL  DDLC  specifications. 

2.  The  design  used  to  support  CODASYL  DDLC  database 
aanagers  aust  be  expansible  to: 

A.  Hierarchical  Database  Managers 

B.  Index  Sequential  Files 

Note:  Paragraph  2  results  froa  a  verbal  request  froa 
the  ICAM  prograa  office. 

Test 

Cl. 4  -  Traceable  Messages 

Tracing  of  aessages  is  supported  to  facilitate  the 
debugging  and  testing  of  the  Test  Bed  software. 

DESIGN 

Cl. 5  -  Query  Transactions 

Query  transactions  use  the  Test  Bed  Neutral  Data 
Manipulation  Language  (NDML)  to  query  Coaaon  Data 
contained  in  the  databases  integrated  by  the  Test  Bed. 
These  query  transactions  allow  access  to  Class  II  data. 

Cl. 5.1  -  Integrated  Application  Processes 
Integrated  application  processes  use  query  transactions 
to  query  Common  Data.  Updates  are  only  performed  on 
the  database  bound  to  the  application.  These  updates 
are  performed  without  supervision  of  the  Common  Data 
Model . 

Cl. 6  -  Migration  To  Class  I  Integration 
The  Early  Implementation  Test  Bed  is  restricted  to 
Class  II  data  integration  to  satisfy  the  schedule  and 
dollar  constraint  of  the  project.  However,  enhancements 
to  the  Test  Bed  will  strive  to  include  Class  I  data 
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integration.  The  Early  Implementation  design  must  be 
eoapatible  with  a  Test  Bed  Class  I  design. 

Cl. 7  -  Class  II  Data  Integrity  Cheeking 
The  data  integrity  cheeks  are  perforaed  selectively  on 
data  being  updated  or  retrieved.  In  test  aode.  these 
checks  are  perforaed  in  a  Mandatory  fashion.  (Future) 

Cl. 7.1  -  Message  Integrity  Checking 

Message  integrity  checks  are  perforaed  selectively  on 
Messages  exchanged  in  the  Test  Bed.  These  checks 
include  edit,  doaain  and  range  cheoking  of  the 
inforaation  conveyed  in  the  Message.  (Future) 

Cl. 8  -  Miniaize  Modifications  to  Host  Operating  Systeas 
The  design  of  the  Test  Bed  ainiaizes  the  number  and  the 
coaplexity  of  the  changes  required  to  the  operating 
systeas  of  the  hosts  ooaputers.  It  is  desirable  that 
such  Modifications  be  avoided,  if  at  all  possible. 

Cl .9  -  Miniaize  Modifications  to  Existing  Application 
Subsysteas 

The  design  of  the  Test  Bed  ainiaizes  the  nuaber  and  the 
coaplexity  of  the  changes  required  to  install  existing 
Application  Subsysteas.  Existing  Application 
Subsystems  may  be  modified  and  recompiled  to  facilitate 
instal lation. 

Cl . 10  -  Transparent  Data  Looation 
A  system  supported  procedure  is  used  by  the  new 
application  processes  to  retrieve  data  distributed  in 
the  Test  Bed  databases.  This  procedure  is  not 
dependent  upon  the  location  of  the  data,  as  viewed  from 
the  application  process. 

Cl. 11  -  Transaction  Processing 

The  Early  Implementation  Test  Bed  provides  transaction 
processing.  This  implementation  is  restricted  to 
preplanned  application  processes. 

Cl. 12  -  Prioritized  Transaction  Processing 
Application  processes  are  prioritized  by  schedule  time 
of  execution  and  by  relative  importance  for  those 
scheduled  to  run  at  the  same  time.  The  priority 
information  is  associated  with  in  the  message 
initiating  the  application  process.  (Future) 
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Cl. 15  -  Predefined  Transaction  Messages 
The  Early  lapleaentation  Test  Bed  relies  on  predefined 
Messages  to  control  the  execution  (initiate,  abort)  of 
predefined  application  processes.  The  foraat  of  the 
predefined  Messages  is  ooapatible  with  the  foraat  of 
Messages  to  be  defined  in  the  Message  definition 
language  which  will  be  developed  as  enhanoeaent  to  the 
Early  lapleaentation  Test  Bed.  (Future) 

Cl. 14  -  Active  Data  Security 

For  the  ad-hoc  environaent,  the  access  to  coaaon  data 
is  discriainatory .  and  is  dependent  upon  the  access 
privileges  of  the  user.  For  predefined,  the 
application  process  environaent  access  to  coaaon  data 
is  granted  to  specific  application  processes.  (Future) 

(R2)  REQUIREMENT  2  -  Provide  Coaaon  User  Interface  to 
Integrated  and  Non- Integrated  Applications  Subsysteas 

Description:  a  Coaaon  User  Interface  to  the  integrated 
and  non- integrated  Application  Subsysteas  and  Test  Bed 
utilities  is  provided. 

Requireaent  2  is  subject  to  the  following  constraints: 
PHYSICAL 

C2.0  -  Coaaon  Terainal  Interface 

A  coaaon  terainal  interface  is  used  to  access  the 
various  Application  Subsysteas  and  Test  Bed  utilities. 

C2.1  -  Virtual  Terainal  Interface 

A  standard  set  of  terainal  features  and  foraats  is 
defined  for  the  Test  Bed.  The  conversion  of  these 
features  and  foraats  to  and  froa  the  specific  features 
and  foraats  of  a  given  terainal  hardware  or  Application 
Subsystea  is  perforaed  by  the  Virtual  Terainal 
Interface . 

DESIGN 

C2.2  -  Consistent  Invocation  and  Control  of  Application 
Subsysteas 

The  User  Interface  provides  the  ability  to  invoke  and  to 
control  the  Application  Subsysteas  included  on  the  Test 
Bed.  The  User  Interface  does  not  depend  upon  the  host 
on  which  the  Application  Subsystea  reside.  The  User 


SRD620 140000 
1  November  1985 


Interface  is  only  available  to  the  Test  Bed  users. 

C2.3  -  Invocation  and  Control  of  Test  Bed  Utilities 
The  User  Interface  provides  the  ability  to  invoke  and  to 
control  the  utilities  provided  by  the  Test  Bed  System 
(user  help  facility,  menu  selection  program,  etc.). 

C2.4  -  Extensibility,  Flexibility  of  User  Interface 
The  User  Interface  is  extensible  and  flexible.  It 
allows  new  functions  and  new  hosts  to  be  supported. 

C2.5  -  Application  Subsystem  Security 
The  User  Interface  controls  the  access  of  users  to  the 
various  Test  Bed  Application  Subsystems .  The 
information  required  to  support  this  function  is 
provided  by  the  Test  Bed  system  control  and  common  data 
description  repository. 

C2.6  -  Centralized  User  Interface  Support  Data 
The  User  Interface  support  data  (forms,  error  messages, 
etc.)  is  centrally  controlled  to  improve  User  Interface 
consistency.  (Partial) 

C2.7  -  Forms  Generator 

A  general  purpose  forms  generator  is  provided  to  enhance 
the  flexibility  of  the  User  Interface  for  new 
Application  Subsystems  and  Test  Bed  utilities. 

C2.8  -  Report  Generator 

A  general  purpose  report  generator  is  provided  to 
enhance  the  flexibility  of  the  User  Interface  for  new 
Application  Subsystems.  The  report  generator  is  not 
included  in  the  Early  Implementation  Test  Bed.  (Provided 
in  Release  2.0) 

•  (R3)  REQUIREMENT  3  -  Measure  and  Report  System 

Performance  (Future) 

Description:  the  Test  Bed  resource  usage  and 

transaction  frequency  and  performance  are  monitored  to 
support  the  objective  assessment  of  the  Test  Bed. 

Requirement  3  is  subject  to  the  following  constraints: 

PERFORMANCE 

C3.1  -  Measure  Elapsed  Time  and  Response  Time  Within  the 
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Time  Resolution  of  the  Ho6t  Operating  Systems 

C3.2  -  Measure  Transaction  Frequency,  Elapsed  Tine, 
Response  Tine,  and  Provide  Selective  Reporting 
User  and  system  transaction  frequency,  elapsed  tine,  and 
response  tine  will  be  measured.  Totals,  means  and 
standard  deviations  of  the  transaction  measures  are 
selectively  provided  upon  request. 

C3.3  -  Measure  Test  Bed  Resource  Usage,  and  Provide 
Selective  Reporting 

Measure  the  usage  of  the  Test  Bed  hardware  and  software 
resources.  These  measurements  include  the  usage  of  the 
Test  Bed  hosts  and  of  the  Test  Bed  local  area  network. 
Totals,  means  and  standard  deviations  of  these 
measurements  are  selectively  provided  upon  request. 

C3.4  -  Use  Vendor  Supported  Resources  Monitors 
Resource  usage  monitors  provided  by  the  various  vendors 
are  used  to  the  maximum  extent  possible  to  reduce  system 
overhead . 

C3.5  -  Support  User  Accountability 

An  audit  trail  is  kept  on  users  and  data  that  are 

entered . 

(R4)  REQUIREMENT  4  -  Provide  Test  Bed  System  Control 

Description:  1)  Control  the  Test  Bed  system 
2)  Maintain  operability 

Requirement  4  is  subject  to  the  following  constraints: 
PHYSICAL 

C4.1  -  Provide  Communication  Between  Application 
Processes  The  Test  Bed  provides  communication  services 
to  facilitate  communication  between  Application 
Processes  and  other  Test  Bed  software. 

C4.2  -  Provide  Active  Routing  of  Transaction  Messages 
Transaction  messages  are  automatically  routed  in  the 
Test  Bed.  The  information  required  to  route  the 
transaction  messages  is  supplied  by  the  system  oontrol 
information  repository. 

C4.3  -  Control  Execution  of  Application  Processes 
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The  execution  of  Application  Processes  is  controlled  by 
transaction  Messages.  These  Messages  are  used  to 
initiate,  to  abort  and  to  redirect  the  I/O  of  new  or 
existing  Application  Processes. 

C4.4  -  Provide  Error  Processing 

1.  Detect  and  log  the  errors  originating  in 

a.  Transnission  of  Messages 

b.  Retrieval  and  Manipulation  of  system  and  Connon 
Data  control  inforaation 

c.  Execution  of  any  program  part  of  the  Test  Bed 
systen 

2.  Support  the  error  processing  capabilities  provided 
by  the  Application  Processes  prior  to  their 
installation. 

C4.5  -  Maintain  Test  Bed  Operability 

e  Test  Bed  start-up 

e  Test  Bed  shut  down 

•  Test  Bed  host  restart/stop 

•  Test  Bed  back-up  (Future) 

•  Test  Bed  Subsystem  (cf:  Local  Area  Network,  etc.) 

restart/stop 

(34. 6  -  Support  Test  Bed  Recovery  (Future) 

1.  Automatic  recovery  and  synchronisation  of  databases 
following  abnormal  termination  of  Application 
Processes,  to  the  extent  supported  by  the  local 
database  managers . 

2.  Manual  recovery  and  synchronization  of  databases 
for  other  abnormal  operating  conditions  (crash, 
etc.),  to  the  extent  supported  by  the  looal 
database  managers . 

C4.7  -  Provide  Message  Guarantee  Delivery  Service 
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1.  The  delivery  of  Test  Bed  Messages  nay  be  guaranteed 
to  occur ,  even  though  the  destination  process  is 
not  available  at  the  tine  the  nessage  is  generated. 

2.  Even  though  the  delivery  of  the  nessage  nay  be 
guaranteed .  no  constraint  is  plaoed  on  the  tining 
of  the  delivery. 

e  (R5)  REQUIREMENT  5  -  Maintain  Test  Bed  Systen 

Control  Inforaation 

Description:  The  inforaation  supporting  the  active  Test 
Bed  systen  and  connon  data  control  aust  be  aaintained. 
Maintenance  functions  include  the  creation,  deletion, 
updating  and  retrieval  functions. 

Requireaent  5  is  subject  to  the  following  constraints: 
PHYSICAL 

C5.1  -  Centralized  Systen  and  Connon  Data  Control 
The  inforaation  required  to  control  Systen  (Future)  and 
Connon  Data  is  centrally  controlled. 

C5.2  -  Controlled  Access  of  Systen  and  Connon  Data 
Control  Inforaation 

The  description  of  the  connon  data  is  protected,  and  is 
supplied  to  authorized  users  only. 

C5.5  -  Flexibility  of  the  Connon  Data  Control  Structure 
The  Connon  Data  Control  Structure  can  describe  a  wide 
variety  of  different  data  structures.  It  can  be 
extended  without  disrupting  Test  Bed  services. 

(Partial ) 

C5.4  -  Test  Bed  Systen  Control  Migration 

The  structure  of  the  Test  Bed  systen  control  infornation 

allows  nigration  to  a  back  end  data  nachine. 

C5.5  -  The  Maintenance  of  the  Test  Bed  Control 
Infornation  Is  Conputer  Assisted 
Conputer  supported  functions  assist  the  user  in 
creating,  deleting,  updating,  retrieving  and  checking 
the  infornation  used  to  support  the  control  of  the  Test 
Bed  Systen  and  Connon  Data. 
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DESIGN 

C5.6  -  A  Couon  Data  Model  Supports  the  System  and 
Common  Data  Control  Information 

A  complete  description  of  the  couon  data  is  required  to 
achieve  integration.  This  description  is  supported  by  a 
well  defined  structure  that  allows  for  the  description 
of: 

1.  Entity  classes  and  the  relations  among  then 

2.  Mappings  between  entity  classes  and  their  attribute 
classes 

3.  Constraints  which  define  permissible  values  for 
attributes 

C5.7  -  Selective  Access  to  the  Maintenance  Functions 
Access  to  the  system  control  information  maintenance 
functions  is  provided  to  authorized  users  only. 

e  (R6)  REQUIREMENT  6  -  Provide  Capability  to  Implement  and 
Test  Programs  on  Test  Bed 

Description:  the  Test  Bed  should  provide  an  environment 

to  allow  new  programs  to  be  tested  and  installed  into 
the  total  system. 

06.1  -  Protect  System  from  New  Application  Programs 
(Future) 

During  testing,  the  new  application  programs  should  be 
prevented  from  making  unauthorized  changes  to  the  system 
including  the  system  data. 

C6.2  -  Provide  Real  Data  for  Testing 

A  capability  shall  be  provided  to  allow  real  data  to  be 
used  during  testing,  but  to  prevent  modifying  any 
protected  system  data  or  Application  Subsystem  data. 
(Protection  -  Future) 

06. 3  -  Make  Maximum  Use  of  Vendor  Supplied  Utilities 
The  vendor  supplied  utilities  should  be  used  where 
possible  for  development  and  test.  Actual  development 
will  be  host  dependent,  but  provisions  must  be  made  to 
introduce  and  use  the  Test  Bed  capabilities  as  the 
program  is  integrated  into  the  total  system. 
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06.4  -  Allow  Analysis  of  Message  Journals 
A  capability  will  be  provided  to  allow  analysis  of 
message  journals  for  messages  affecting  a  given  program. 

06.5  -  Test  Bed  May  Be  Shutdown  for  Special  Conditions 
The  Test  Bed  is  not  required  to  run  continuously,  and 
can  be  shutdown  under  speoial  conditions. 

06.6  -  Test  Results  Shall  Be  Accessible 
The  results  of  calculations  and  data  updates  made  during 
testing  shall  be  available  to  the  programmer  even  if  the 
results  are  not  permanently  stored. 

06.7  -  Tests  Shall  Be  Repeatable 

It  shall  be  possible  to  repeat  tests  with  known  test 
data. 

06.8  -  Test  Protection  Modes  Shall  Be  Easily  Changeable 
The  degree  of  protection  of  a  program  and  the  data  it 
references  shall  be  easily  changeable .  though  with 
proper  access  security  to  provide  reasonable  protection 
for  the  total  system.  (Partial) 

SCI  -  GENERAL  SYSTEM  CONSTRAINTS 

The  Test  Bed  must,  in  addition,  satisfy  the  following 
constraints . 

PERFORMANCE 

SC1.1  -  Engineering  Trade-Offs  Consider  Impact  on 
Performance 

The  Test  Bed  is  experimental  in  nature,  and  its  expected 
level  of  performance  cannot  be  quantified.  Careful 
design  trade-offs  are  made  to  minimize  user  response  and 
elapsed  time. 

SCI. 2  -  Test  Bed  Design  Is  Expansible 

The  Test  Bed  design  allows  reasonable  expansion  of  the 
number  of  users  and  Application  Subsystems  to  be 
accommodated,  subject  to  environmental  constraints. 

SCI. 3  -  Test  Bed  Performance  Improvements 

The  Test  Bed  design  allows  improving  performance  through 

reconfiguration  of  hardware  and  software. 
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SCI. 4  -  Heterogeneous  Hardware  Environment 

The  Early  Implementation  Test  Bed  is  implemented  by 

interconnecting : 

1.  A  Vax  11/780  under  VMS 

2.  A  Honeywell  Level  6  under  G00S6/M0D400  OS 
S.  An  IBM  3033  under  MVS 

SCI. 5  -  Geographic  Constraint 

The  Vax  11/780  and  the  Honeywell  Level  6  are  located  in 
Building  4  of  the  General  Electric  Schenectady  complex. 
The  IBM  3033  is  located  at  the  General  Electric  CIPO 
facility.  (GE's  main  facility  later  moved  to  Albany,  NY, 
and  IBM  support  to  GE/Rookville,  Md. ,  and  then  to 
Boeing/Vichita.) 

SCI. 6  -  Local  Area  Network  Requirements 
A  standard,  commercially  available.  Local  Area  Network 
system  is  used  to  interconnect  the  Test  Bed  host 
computers.  Owing  to  the  geographic  constraint  bearing 
on  the  Early  Implementation  Test  Bed,  wide  area  services 
are  required  to  interconnect  the  IBM  3033  to  the  local 
area  network. 

SCI. 7  -  Heterogeneous  database  Management  Systems 
The  Early  Implementation  Test  Bed  integrates  Application 
Subsystems  or  appropriate  test  programs  supported  by  the 
following  database  management  systems: 


1 . 

Honeywell  Level  6  : 

IDS  II 

2. 

Vax  11/780 

I  DBMS 

3. 

IBM  3033 

Codasyl  DBMS  Supporting 
Selected  MRP. 

[Later  extended  to  VAX-11  DBMS  and  ORACLE  on  VAX,  IDMS 
(Cullinet),  TOTAL,  and  IMS  on  IBM] 

SCI. 8  -  Test  Bed  Terminals 

The  Test  Bed  terminals  are  ASCII  terminals  which  are 
supported  by  the  vendor  supplied  host  operating  systems 
and  which  provide  the  following  capabilities: 

1.  Scroll  mode 
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8.  Cursor  position  oontrol 
S.  Clour  soroon 


4 .  Foros  node 


In  addition,  graphic  capabilities  coapatible  to  the 
Tektronix  4014  or  4112  are  desirable  to  support  the 
animation  capabilities  of  IDSSN2.0. 


8C1.9  -  Technology  Transfer  by  1  Feb  83 

The  Test  Bed  design  is  constrained  to  provide 

integration  technology  in  the  Early  Inplenentation. 

SCI. 10  -  Test  Bed  Hardware  is  Expansible 
The  Test  Bed  hardware  design  allows  for  expansion,  and 
is  not  restricted  to  the  Early  Inplenentation  hardware 
conf igurat 1 on . 

TEST 

SCI. 11  -  Test  Configuration 

Test  programs  or  selected  functions  taken  fron  new  or 
existing  Application  Subsystens  are  used  to  test  and 
denonstrate  the  Test  Bed  software  and  concepts. 

SCI. 12  -  Modular  Testing,  Phased  Integration 
The  design  of  the  Test  Bed  supports  the  testing  of 
individual  nodules  and  a  phased  integration. 

SCI. 13  -  Denonstrati on  of  Class  II  Integration 
The  Test  Bed  scenarios  support  the  demonstration  of 
Class  II  integration. 

SCI. 14  -  MCMM,  IDSS  2.0  and  MRP  Demonstration 
The  Test  Bed  demonstrates  the  operations  of  selected 
functions  belonging  to  MCMM  and  IDSS  2.0,  in  an 
integrated  environment.  The  Test  Bed  also  includes 
specific  functions  fron  an  MRP  system  to  be  selected. 
[IDSS  2.0  runs  as  a  stand-alone  application  subsystem] 

SCI. 15  -  MRP  Selection  Criterion 

The  MRP  system  to  be  selected  is  subject  to  the 

following  constraints: 

1.  Runnable  on  IBM  3033,  under  MVS. 
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2.  Relies  on  OODASTL  database  manager . 

3.  Adheres  to  6201  Standard  Guidelines  and  Procedures. 
DESIGN 

SCI . 16  -  The  System  and  Coneon  Data  Control  Promotes 
Integration  Through  Sharable  databases 

SCI. 17  -  The  Test  Bed  Architecture  is  Layered  and 
Modular 

SCI . 18  -  The  Test  Bed  Software  Adheres  to  the  Test  Bed 
Standard  Guidelines  and  Procedures 

SCI. 19  -  The  Test  Bed  Software  Is  Extensible  and 
Flexible 

The  Test  Bed  design  is  extensible  and  flexible.  That 
is.  new  technological  developments  and  added 
functionality  can  be  readily  accomodated. 

SCI. 20  -  Physical  and  Logical  Data  Structures  and 
Addresses  Are  Decoupled 

SCI. 21  -  The  Test  Bed  Software  Is  Portable 
The  Test  Bed  is  implemented  to  maximise  software 
portability.  Reliance  on  host  specific  features  must  be 
minimized. 


SCI. 22  -  Binary  Data  Transfer 

The  Test  Bed  design  allows  the  transfer  of  binary  files. 
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SECTION  3 

SYSTEM  SPECIFICATION 


3.1  Scope 

3.1.1  Identification 


This  specification  establishes  the  prioritised  detailed 
functional  requirements  for  the  I CAM  Integrated  Information 
Support  System  (IISS)  Test  Bed.  This  system  is  intended  to  be  a 
test  computing  environment  providing  integrated  data  management 
facilities  and  distributed  processing  for  heterogeneous 
databases  resident  on  heterogeneous  computer  systems 
interconnected  via  a  Local  Area  Network. 

This  document  has  been  prepared  by  Project  Priority  6201  of 
the  Air  Force's  I CAM  Program.  This  project  is  being  conducted 
by  the  General  Electric  Company,  with  the  participation  of 
SofTech,  Inc.  and  of  Control  Data  Corporation,  supported  by 
various  consultants  and  contributors. 

This  project  is  sponsored  by  the  Manufacturing  Technology 
Division  of  the  Air  Force  Wright  Aeronautical  Laboratories. 

3.1.2  Purpose 

The  purpose  of  this  document  is  to  decompose  the  system 
requirements  to  the  maximum  extent  possible,  to  assure  validity 
of  the  requirements  and  to  promote  maximum  understanding  between 
ICAM  Program  Office  personnel.  General  Electric  and  the 
development  subcontractors  before  system  design  begins. 

3 . 2  References 


3.2.1  Applicable  Documents 

1.  Systran,  Inc.,  ICAM  Documentation  Standards,  ICAM 
Document  IDS  150120000,  28  Dec  81. 

2.  A.D.  Little,  ICAM  Computer  Based  Information  System 
(CBIS) ,  System  Environment  Document,  ICAM  Document  SED 
310140000,  Sept  81. 

3.  A.D.  Little,  ICAM  Computer  Based  Information  System 
(CBIS) .  State  of  the  Art  Document .  ICAM  Document  SAD 
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S10140000 ,  Sept  81. 

4.  A.D.  Little,  ICAM  Computer  Based  Information  System 
(CBIS) .  System  Requirement  Document ,  ICAM  Document  SRD 
310140000,  Sept  81. 

5.  Control  Data  Corporation,  System  Requirements 
Document . 

6.  General  Electric  Company.  Test-Bed  System  Requirements 
Document .  Revised  June  11,  1982. 

7.  SofTech,  ICAM  Test-Bed  Interim  Standards  and 
Procedures,  ICAM  Dooument  ISP  620150000.  February 
1982. 

8.  ICAM  Program  Office,  The  Integrated  Sheet  Metal 
Center ,  30  Sept  81. 

9.  H.  Tupper,  Memorandum  for  the  Record,  5  Oct  81. 

10.  SofTech,  IISS  Test  Bed  Network  Transaction  Manager 
System  Design  Specification.  Document  1098-7,  June 
1982. 

3.2.2  Terms  and  Abbreviat i ons 


See  Section  1.4  of  this  document. 

3.3  Requirements 

This  subsection  is  written  from  the  point  of  view  of  the 
System  Engineer  for  the  purpose  of  allocating  functional 
specifications  to  the  Requirements,  Constraints  and  System 
Constraints  listed  in  the  System  Requirement  Document  (Section  2 
of  this  document).  The  System  Specification  is  the  first 
document  in  the  life  cycle  which  addresses  the  implementation 
aspects  of  the  system  design. 

In  the  following,  the  requirements  are  identified  by  unique 
R  numbers  (Ex:  R3),  the  constraints  are  identified  by  unique  C 
numbers  (Ex  C  1-1)  and  the  functional  specifications  are 
identified  within  each  constraint  by  sequential  F  numbers  (Ex: 
F3)  . 
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3.3.1  Functional  Requirements 

R1  Data  Sbareability  Between  New  or  Existing  I CAM  Application 

Processes 

Cl .0  Query  Capabili ties 

FI  Predefined  query  capabilities  are  provided  to 
enable  Integrated  Processes  to  query  data 
contained  in  the  Test  Bed  databases 
F2  Predefined  query  capabilities  provided  are 
non-pr ocedur a 1 

Cl. 01  Deadlock  Resolution 

FI  Prevent  system  deadlocks  by  designing  out 
database  managers  deadlock  (Future) 

F2  Local  host  oomputer  system  capabilities  are 
relied  upon  for  preventing,  detection  and 
resolution  of  local  dead  locks 

Cl . 1  Heterogeneous  Computer  Systems 

FI  Provide  system  capabilities  to  support  conversion 
of  messages  to  specific  host  internal 
r epresentat i on 

Cl. 2  Heterogeneous  Database  Managers 

Mo  functional  requirements  identified 

Cl. 3  CSODASYL  Databases  /  Database  Structures 


FI 


The  following  CODASYL  databases  are  supported: 


VAX/VMS 

IBM  3033 
LEVEL  6 


I DBMS  FOR 

VAX 11  DBMS  FOR 
IDMS  FOR 

IDS  II  FOR 


IDSS  III. 2.0 
MCMM 

MRP  System 
MCMM 


F2  The  design  will  be  extensible  to  allow  the 

following  non-Codasyl  database  management  systems 
to  be  supported: 

IBM  3033  IMS 

IBM,  VAX,  UHIVAC  ISAM  FILES 

[Release  2.0:  The  design  was  extended  to  support 

ORACLE  on  VAX.  and  TOTAL  and  IMS  on  IBM] 
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Cl. 4  Traoeable  Messages 

FI  Messages  are  uniquely  identified 

F2  Messages  are  tagged  by  origin 

FS  Messages  are  tagged  by  destination 

F4  Message  logs  are  selectively  accessible 

F9  Message  logs  can  be  sorted  in  chronological  order 

F6  Message  log6  can  be  sorted  by  origin 

F7  Message  logs  can  be  sorted  by  destination 

F8  Message  logs  are  selectively  cleared 

F9  Message  logs  are  oentrally  accessible  (Future) 

F10  Message  logs  can  be  enabled/disabled  by  the 
Conon  Data  Administrator  (Future) 

Fll  Messages  are  defined  in  the  Conon  Data  Model 
(Future) 

Cl. 9  Query  Transactions 

FI  Predefined  retrieve  only  application  processes 
will  be  supported  by  end  of  oontraot 
F2  Query  application  processes  to  Class  II  data  are 
specified  in  the  Meutral  Data  Manipulation 
Language  (MDML) 

FS  The  Meutral  Data  Manipulation  Language  (MDML)  is 
non -procedural  (non-navigational ) 

F4  Query  format  is  independent  of  target  database 
F9  Query  implementation  is  independent  of  target 
data  structure 

F6  Support  migration  to  ad-hoc  query 

F7  Access  data  contained  in  more  than  one  database 

F8  Support  select  capabilities 

F9  Support  join  capabilities 

F10  Support  project  capabilities 

Fll  Perform  unit  conversion  between  data  units 

(example  metric/  English).  The  data  required  to 
support  the  data  conversion  operations  is  defined 
in  the  CDM 

F12  Error  status  can  be  provided  to  query  originator 
F13  The  data  checking  operations  defined  in  Cl. 7 
F14  The  common  data  queried  by  the  query  application 
processes  is  described  in  the  Common  Data  Model 

Cl. 9.1  Integrated  Application  Processes 

FI  Integrated  applications  use  query  transactions 
(Cl. 9)  to  query  data  contained  in  Test  Bed 
databases . 
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F2  A  pre-compiler  is  used  to  preprooes6  new 
applications  which  utilise  neutral  DML 
statements . 

FS  By  end  of  contract,  the  pre -compilation  may  be 
manually  performed.  [Extended  to  be  automatic] 

F4  Integrated  application  processes  query  Class  II 
data. 

Cl. 5. 2  Boa-Integrated  Application  Processes 

FI  Bon- integrated  application  process  queries  and 
updates  the  database  to  whioh  it  is  bound. 

F2  Bon- integrated  application  processes  are  not 

supervised  by  the  Common  Data  Model  processor. 

FS  Data  integrity  checks  may  be  performed  on  data 

supplied  to  a  non- integrated  application  process. 

F4  Data  integrity  oheoks  are  performed  on  data 

supplied  by  a  non- integrated  application  process 
to  the  Test  Bed.  (Future) 

Cl .6  Migration  to  Class  I  Data 

FI  The  Test  Bed  design  supports  migration  to  Class  I 
data  environment. 

Cl. 7  Class  II  Data  Integrity 

FI  Class  II  data  integrity  checks  include: 

o  Edit  Checking  (Ex:  7  Alpha  Characters) 
o  Domain  Checking  (Ex:  shirtsize:  small, 

medium) 

o  Range  Checking  (Ex:  o,  n,  15) 

F2  Data  integrity  checks  are  performed  selectively. 
The  information  required  to  support  and  control 
these  checks  are  contained  in  the  CDM.  This 
information  may  be  distributed  to  improve 
performance.  Data  cheoking  selection  is  made  by 
query. 

FS  Standard  error  messages  are  issued  to  the  data 
query  originator  when  data  integrity  cheoks  are 
violated.  The  text  of  the  error  message  is 
contained  in  the  CDM. 

F4  Error  correction/disposition  action  is  selected 
and  performed  by  the  data  query  originator 

F5  Error  messages  are  logged  and  are  selectively 

accessible  from  a  central  location.  [Release  2.0 
-  Aooessible  on  eaoh  host] 
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Cl. 7.1  Message  Integrity  Checking 

FI  Message  integrity  cheoks  include: 
o  Edit  Checking 
o  Domain  Checking 
o  Range  Checking 

F2  The  format  of  the  messages  and  information 

required  to  support  and  oontrol  message  integrity 
checking  is  contained  in  the  CDM. 

F3  Standard  error  messages  are  issued  when  message 
integrity  cheoks  are  violated.  When  possible, 
the  message  originator  is  notified  of  the 
violation. 

F4  Error  correction/disposition  action  is  selected 
by  the  system  administrator,  and  is  implemented 
by  the  distributed  services  of  the  Test  Bed. 

F5  Error  messages  are  logged  and  are  centrally 

accessible.  [Rel  2.0  -  Accessible  on  each  host] 

F6  Message  integrity  checks  can  be  enabled/disabled 
by  message  type,  by  source  and  by  destination. 
(Future) 

Cl. 8  Minimize  Modifications  to  Host  Operating  Systems 

FI  Modifications  to  the  host  operating  systems  will 
be  limited  to  I/O  device  drivers,  and  these 
modifications  will  be  made  only  if  they  are 
necessary. 

Cl. 9  Minimize  Modifications  to  Existing  Application 

Subsystems 

FI  Redirection  of  application  processes  terminal 

input/output  on  the  host  computer  systems  may  be 
required. 

Cl . 10  Transparent  Data  Location 

FI  NDML  query  format  is  independent  of  data  location 

F2  Data  locations  are  contained  in  the  Common  Data 
Model 

F3  Integrated  application  processes  need  not  know 
the  location  of  Class  II  data 

Cl. 11  Transaction  Processing 
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FI  Application  processes  perform  predefined  data 
processing  tasks. 

F2  Only  predefined  application  processes  are 
provided  by  end  of  contract. 

75  Application  Processes  can  execute  without  user 
interaction. 

Cl. 12  Prioritised  Transaction  Processing 

FI  Application  prooess  release  to  the  local  host 

operating  systea  can  be  scheduled  by  wall  dock 
time,  or  by  relative  priority  within  the  host. 
(Future) 

F2  Application  process  execution  is  controlled  by 
the  host,  in  its  local  environment. 

F3  Application  prooess  priority  is  assigned  by  the 
CDM  Administrator  and  is  stored  in  the  CDM. 
(Future) 

F4  Application  process  priority  information  can  be 
defined  by  message  type. 

Cl. 14  Active  Data  Security 

FI  Active  data  security  is  provided.  (Future) 

F2  For  predefined  application  processes,  access  to 
common  data  is  granted  via  the  schema  and 
application  process  logic. 

F3  Access  to  predefined  application  processes  is 
controlled  on  a  user  role  basis. 

F4  Data  supporting  application  process  access  control 
is  contained  in  the  Common  Data  Model,  and  can  be 
changed  by  the  CDM  Administrator.  (Future) 

R2  Provide  Common  User  Interface  to  New  or  Existing  Application 

Processes 

C2.0  Common  Terminal  Interface 

FI  A  common  terminal  is  used  for  input  and  for 
output  to  Test  Bed  functions,  integrated  and 
non- integrated  application  processes. 

F2  The  common  terminal  supports  the  following 

functions:  clear  screen,  cursor  positioning, 
scroll  mode,  and  is  supported  by  VAX  VMS. 

C2.1  Virtual  Terminal  Interface 
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FI  The  virtual  terminal  defines  a  standard  set  of 

terninal  features  supported  fey  1188  terminals  and 
recognised  by  ZISS  application  programs. 

F2  The  virtual  terminal  implements  standard 

communication  protoool  to  coamunioate  between 
itself  and  the  hardware  terainal.  AMSI  terminals 
such  as  the  VT-100,  VIP7200  and  ADM-3  are 
supported. 

F3  The  virtual  terminal  defines  a  standard 

communication  protocol  to  ooaaunioate  between  two 
virtual  terminals. 

F4  The  virtual  terminal  defines  a  set  of  oontrol 
words. 

F8  The  virtual  terainal  maps  specific  hardware 
terainal  oontrol  characters  into  the 
corresponding  virtual  terainal  oontrol  words. 

F6  The  virtual  terainal  maps  the  virtual  terainal 
oontrol  words  into  specific  hardware  terminal 
oontrol  characters. 

F7  The  virtual  terminal  implements  the  bidirectional 
virtual  terainal  communication  protocol  (defined 
in  F3) . 

F8  The  virtual  terminal  implements  the  bidirectional 
virtual  to  hardware  terminal  protoool  supported 
by  the  specifio  hardware  terninal  (defined  in 
F2) . 

F9  The  conversions  of  virtual  terminal  control  words 
into  oontrol  character  conversions  are  table 
driven.  (Revised  to  program  code) 

F10  The  implementation  of  the  virtual  terminal  to 
hardware  terainal  protoool  is  table  driven. 
(Revised  to  program  code) 

Fll  The  virtual  terminal  defines  and  implements  a 

standard  data  structure  representing  the  terminal 
image. 

F12  The  Common  Data  Model  contains  administrative 

utilities  for  maintaining  Information  relative  to 
terainal  types.  (Future) 

F13  The  information  relative  to  terminal  types  etc. 

is  provided  to  the  virtual  terainal  by  the  Common 
Data  Model.  (Future) 

C2.2  Consistent  Invocation  and  Control  of  Application 

Subsystem 

FI  The  U6er  Interfaoe  provides  the  ability  to  invoke 
all  application  processes  in  a  consistent 
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fashion. 

P2  The  User  Interface  is  independent  of  the  host  on 
which  the  application  process  of  interest 
resides. 

FS  The  user  need  not  know  on  whioh  host  the 
application  process  of  interest  resides. 

C2.S  Invocation  and  Control  of  Test  Bed  Utilities 

FI  The  User  Interface  provides  the  ability  to  invoke 
all  Test  Bed  Utilities  in  a  consistent  fashion. 

F2  The  User  Interface  is  independent  of  the  host  on 
which  the  Test  Bed  Utility  of  interest  resides. 

FS  The  user  needs  not  know  on  which  host  the  Test 
Bed  Utility  of  interest  resides. 

F4  The  Test  Bed  utilities  can  be  invoked  in  a  novice 
or  in  an  expert  node. 

F5  The  User  Interface  validates  the  entries  wade  by 
the  user.  Error  messages  are  issued  when 
appropriate  and  are  contained  in  tables 
naintained  by  the  Coaaon  Data  Model .  [Message 
Management  tables  independently  managed] 

F6  The  User  Interface  is  tutorial  through  a  help 
facility. 

C2.4  Extensibility.  Flexibility  of  the  User  Interface 

FI  The  User  Interface  provides  a  help  facility.  The 
help  facility  Bakes  use  of  help  messages 
contained  in  the  Common  Data  Model . 

F2  The  User  Interface  allows  the  definition  of  new 
application  processes,  and  new  Test  Bed 
Utilities. 

FS  The  User  Interface  services  may  be  invoked  by  an 
Integrated  Application  for  user  interaction. 

F4  The  semantic  contents  of  user  entries  recognised 
by  the  User  Interface  must  be  readily  changeable. 

F5  User  entry  syntax  and  semantics  to  invoke 

application  processes  and  Test  Bed  services  are 
stored  in  the  Common  Data  Model.  [Defined  in  UI 
and  forms] 

F6  The  textual  contents  of  the  User  Interface  forms 
is  supplied  to  the  User  Interface  by  the  Common 
Data  Model.  [Defined  in  forms  definitions] 

F7  A  form  restore/refresh  capability  is  provided. 

F8  The  Help  Utility  can  be  invoked  within  a  sequence 
of  forms . 


3-9 


SRD620 140000 
1  Wovenber  1985 


F9  The  User  Interface  provides  a  Help  Facility  which 
is  table  driven.  The  Help  Facility  can  be 
invoked  without  exiting  the  ooaawnd  node  of  the 
User  Interface.  Exiting  fron  the  Help  Facility 
leads  back  to  the  ooaaaad  node  (Indirection). 

C2.5  Application  Subsysten  Security 

FI  Access  to  the  various  application  processes  is 

controlled  by  user  role.  User  role  is  established 
by  the  user  logon  prooess. 

F2  The  inforaation  required  to  support  the  Test  Bed 
application  process  aooess  oontrol  is  contained 
in  the  Coaaon  Data  Model.  [In  UI  files] 

FS  The  Connon  Data  Model  oontains  the  administrative 
utilities  to  update,  delete  and  nodify  the  access 
control  data.  (Future) 

F4  Access  to  application  processes  are  logged.  The 
log  contains  sufficient  Inforaation  to  uniquely 
identify  the  user. 

F5  Aooess  to  the  Coaaon  Data  Model  administrative 
utilities  is  controlled.  User  aooess 
authorisation  is  required. 

C2 .6  Centralised  User  Interface  Support  Data 

FI  The  data  required  to  support  the  User  Interface 
is  contained  in  the  Coaaon  Data  Model.  (Future) 

F2  The  Coaaon  Data  Model  processor  contains  the 

administrative  utilities  to  update,  delete,  and 
modify  the  User  Interface  support  data  (security, 
syntax,  semantic  oontents,  etc.). 

F3  Access  to  the  adainistrative  utilities  used  to 
aodify  the  User  Interface  data  is  selective. 

C2 . 7  Forms  Generator 

FI  The  foras  generator  is  used  to  define,  aodify, 
delete  and  test  foras. 

F2  The  data  used  to  define  a  fora  is  stored  in  the 
Coaaon  Data  Model.  (Future) 

F3  Access  to  the  foras  generator  adainistrative 
utilities  is  selective. 

F4  The  foras  generator  allows  the  definition  of  a 
fora  by  using  foras  already  defined. 

F5  A  fora  is  uniquely  identified  by  its  name. 

F6  A  fora  consists  of  fields,  each  of  which  is 
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character iced  by  its  attributes. 

The  forms  generator  allows  the  definition  of 
attributes  to  be  deoided  and  selected  from  the 
following  list: 


Field  Attribute 
Protected/unmodif iable 
Numeric 

Alpha 

Non-displayable 
Mon-printable 
Right  justification 
Left  justification 
Mandatory  entry 
Selectable 

Mot  Transmit table 
Blinking/reverse  video 
Scroll 
Page 

Top  justifiable 
Bottom  justifiable 

Color 

Intensity 

Background 

Variable  description 


•  Definition 

Cannot  be  changed 
Contains  only 
numerals 
Contains  only 
alphabetic 
characters 
Used  for  entry 
passwords 
Cannot  be  printed 
locally 

Character  string  may 
be  right  justified 
Character  string  may 
be  left  justified 
Entries  must  be  made 
before  transmission 
Light  pen  or 
equivalent  can  be 
used  (Future) 

For  local  display 
only 

Contents  of  field 
are  highlighted 
Field  is  overwritten 
as  a  scroll 
Field  is  overwritten 
as  a  page 
Lines  may  be 
justified  to  top  of 
field  [NA  -  Delete] 
Lines  may  be 
justified  to  bottom 
of  field 
[NA-Delete] 

Color  of  characters 
when  displayed 
Brightness  of  field 
when  displayed 
Color  of  background 
of  field 

Description  of  the 
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variable  contained 
in  the  Common  Data 
Model 

P8  The  forms  generator  defines  forns  in  a  Banner 
that  is  not  specif io  to  a  given  hardware 
terainal .  The  definition  is  made  in  terns  of  the 
control  words  recognised  by  the  Virtual  Terminal 
Interface . 

F9  The  forms  generator  allows  the  display  of  a  form 
on  the  terminal  of  an  interactive  IISS  user. 

F10  Field  information  defined  in  forms  that  are 

currently  aotive  is  available  to  the  application. 

Fll  The  application  process  which  invoked  the  User 
Interface  can  obtain  the  name  of  the  form 
currently  aotive. 

F12  The  forms  generator  performs  data  integrity 

checking  on  one  or  more  fields  defined  within  a 
previously  displayed  fora. 

FIS  The  forms  generator  writes  information  to  one  or 
more  fields  defined  in  the  current  and  in  the 
previous  active  form  (i .e. ,  two  forms  may  be 
accessed) . 

F14  A  list  of  nested  forms  can  be  displayed. 

Facility  is  provided  to  select  the  form  to  be 
returned  to. 

F15  The  forms  generator  can  be  invoked  by  an 

application  subsystem  or  a  Test  Bed  utility.  The 
name  of  the  form  to  be  6peoified  is  supplied  by 
the  user . 

F16  The  forms  generator  provide  diagnostic  messages 
to  assist  in  the  definition  of  forms. 

Overlapping  and  adjacent  fields  are  detected. 

F17  The  forms  generator  allows  the  definition  of  the 
sise  of  the  largest  form  to  be  displayed.  Error 
messages  flag  overorowding  violation. 

F18  The  forms  generator  supports  the  following 
run-time  diagnostics: 
o  Form  not  supported 
o  Form  not  displayed 

F19  The  forms  generator  allows  for  the  testing  of 
forms . 

C2 . 8  Report  Generator 

Mot  included  in  the  scope  of  the  current  contract. 

[Was  included  in  Release  2.0] 
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R3  Measure  and  Report  System  Performance 

C3. 1  Measure  Elapsed  Tine  and  Response  Time  For  Processing 

a  Transaction  Within  the  Time  Resolution  of  the  Host 

Operating  Systems  (Future) 

FI  Elapsed  times  for  processing  an  application 

process  are  measured  within  the  time  resolution 
of  the  host  operating  system. 

C3.2  Measure  Transaction  Frequency.  Elapsed  Time.  Response 

Time,  and  Provide  Selective  Reporting  (Future) 

FI  Provide  application  process  frequency,  elapsed 

time  and  response  time  statistics  by  application 
process  source  and  destination. 

F2  Provide  totals,  means,  standard  deviations  of 

application  process  measurements  by  source  and  by 
destination. 

F3  Application  process  statistics  are  provided  over 
the  period  of  interest. 

F4  Application  process  time  measurement  resolution: 
TBD. 

F5  Application  process  classification  includes: 

system  and  user  classes.  Additional  subclasses 
of  application  processes  for  performance 
monitoring  purposes:  TBD. 

F6  Performance  measurements  are  selectively  enabled, 
at  the  system  level,  by  the  system  administrator. 

C3.3  Measure  Test  Bed  Resource  Usage,  and  Provide  Selective 

Reporting 

FI  Measure  Test  Bed  resource  (hardware,  software) 
usage  selectively,  by  application  process. 

(Future  except  for  tests  with  special  performance 
tools) 

F2  Test  Bed  resource  measurements  include  Test  Bed 
hosts,  and  Local  Area  Network  as  provided  by  the 
Vendors . 

C3.4  Use  Vendor  Supported  Resources  Monitors 

FI  The  execution  of  vendor  supported  software 

resource  monitors  can  be  controlled  from  Test  Bed 
host  terminals. 
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P2  Resource  monitoring  statistics  can  be  obtained 
froe  Test  Bed  host  terminals. 

C3.5  Support  User  Accountability 

71  Provide  audit  trail  linking  users  to  data 
entered.  (Future) 

F2  Provide  log  of  application  process  usage  by  users 
and  by  time  of  day.  (Partial  -  information  in 
messages  logs) 

R4  Provide  Test  Bed  System  Control 

C4.1  Provide  Communication  Between  Application  Processes 

FI  Application  processes  are  uniquely  addressable. 

F2  Application  process  addresses  can  be  used  to 
identify  the  host  running  the  application 
process . 

F3  A  Local  Area  Network  is  used  to  communicate 
between  hosts.  (Partial) 

F4  The  nodes  of  host  to  host  communications  (virtual 
circuit,  datagrams)  supported  by  the  Test  Bed  are 
TBD . 

F5  Error  messages  are  logged.  Error  messages 
identify  the  requesting  process. 

F6  Messages  are  classified  into  classes  and 

subclasses  to  be  decided.  Message  processing 
functions  are  settable  by  class,  subclass,  origin 
and  destination  TBD. 

F7  Messages  are  prioritised,  according  to  scheduled 
time  of  execution  (within  seconds),  relative 
priority  levels  (256/levels),  or  else  are 
processed  on  a  first-in,  first-out  basis. 

(Partial  -  uses  FIFO  only) 

F8  Messages  are  classified  into  classes,  subclasses, 
to  be  decided. 

F9  Messages  are  prioritized.  (Partial) 

F10  Asynchronous  communication  environment  is 
provided. 

Fll  Application  prooess  Priority  Levels  and  priority 
schemes  are  TBD.  (Future) 

F12  Message  queues  are  recoverable.  (Future  except 
Guaranteed  Delivery  messages) 

F13  Messages  are  selectively  acknowledged  to  the 

source.  Message  acknowledgement  scheme  is  TBD. 

F14  Transmission  error  checking  is  provided.  Error 
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ohecking  Methods  are  TBD. 

F15  Error  Messages  are  stored  in  the  CDM.  (Future) 

F16  The  guaranteed  delivery  of  Messages  is  provided 
selectively.  The  inforaation  controlling  the 
guaranteed  delivery  servioe  is  contained  in  the 
CDM  (Future).  Guaranteed  delivery  control 
inforaation  can  he  defined  by  Message  type, 
souroe,  destination,  and  is  carried  in  the 
Message.  (Message  type  only) 

C4.2  Provide  Active  Routing  of  Transaction  Messages 

FI  The  autonatic  routing  of  the  Messages  is 
provided. 

F2  The  inforaation  required  to  route  the  Messages  is 
contained  in  the  Coanon  Data  Model .  [NTM  System 
Data,  not  CDM] 

F3  Routing  of  a  Message  to  a  non -ava i 1  able  or 

non-existing  resource  results  in  an  error  Message 
being  sent  to  the  originator.  (Partial) 

C4.3  Control  Execution  of  Application  Processes 

FI  Messages  are  used  to  load,  initiate,  cancel  a 
specific  application  process. 

F2  Messages  are  used  to  control  the  redirection  of 
the  I/O  of  a  specific  application  process. 
(Future) 

F3  Messages  controlling  the  execution  of  application 
Messages  are  selectively  acknowledged  by  the 
receiver:  status  inforaation  and  error  messages 
are  provided  to  the  sender. 

F4  Error  Messages  with  unique  identification  of  the 
sender  and  receiver  processes  are  logged  and  are 
centrally  accessible.  [Accessible  on  each  host] 

F5  Messages  are  prioritized.  (Partial) 

F6  Abort  Messages  have  the  highest  priority. 

(Future) 

C4.4  Provide  Error  Processing 

FI  Error  detection  is  provided  during  the  retrieval 
and  Manipulation  of  information  contained  in  the 
Conmon  Data  Model. 

F2  Error  messages  resulting  from  transmission  errors 
or  Common  Data  Model  errors  (processing  or  data) 
are  logged,  and  are  centrally  accessible.  If 
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possible,  the  originating  user  or  process  will  be 
notified.  The  interpretation  of  error  sassages 
and  their  resolution  is  left  to  the  originating 
user  or  prooess  if  it  oan  be  notified. 

Otherwise,  the  interpretation  of  error  Messages 
is  performed  by  the  Test  Bed  distributed 
services.  [Error  Log  per  host  only) 

F5  The  Test  Bed  supports  the  same  level  of  error 

processing  capabilities  than  that  provided  by  the 
application  program  prior  to  their  installation. 
F4  Error  calls  to  local  host  operating  sy6temB  are 

trapped  and  handled  as  described  in  F2.  (Partial) 

Maintain  Test  Bed  Operability 

.  1  Test  Bed  Cold  Start 

FI  Provide  IISS  bootstrap  capabi 1 ities  on  all  IISS 
hosts . 

F2  Test  Bed  cold  start  functions  support: 

1.  Host  to  host  communication  (LAM  Start-up) 

2.  Aooess  to  Common  Data  Model  for  all  hosts 

3.  User  interface 

4.  Resource  and  performance  logging  (Future) 

5.  Downloading  of  IISS  configuration  data  (LAN) 
from  CDM  (Future) 

6.  System  synchronization  (TBD) 

7.  System  coordination  (restart,  shutdown) 

F3  Completion  of  the  cold  start  phase  is  detected 
and  reported  to  the  Operator  Console. 

F4  Abnormal  conditions  encountered  during  cold  start 
are  logged  and  displayed  on  the  system  operator 
terminal 

F5  Provide  LAN  bootstrap  capabilities 
.2  Test  Bed  Shutdown 

FI  Provide  for  the  orderly,  graceful  shutdown  of  the 
Test  Bed 

F2  Test  Bed  shutdown  does  not  result  in  loss  of  user 
data  [except  abnormal  shutdowns] 

F3  Test  Bed  shutdown  completion  is  detected  and 
reported  to  the  Operator's  Console 
F4  Test  Bed  shutdown  is  initiated  by  the  Test  Bed 
operator 

F5  Control  access  to  the  Test  Bed  shutdown  function 
F6  Shutdown  of  the  Test  Bed  occurs  after  the  system 
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reaches  a  quiet  point  [within  tine  limit] 

F7  Initiation  of  the  Test  Bed  shutdown  sequence 
inhibits  further  Test  Bed  user  logins 
F8  Test  Bed  users  are  notified  when  a  shutdown 

sequence  is  initiated  and  given  reasonable  tine 
to  finish  up 

C4.5.3  Test  Bed  Host  Restart 

FI  Provide  for  the  restart  of  IISS  services  on  a 
host  by  host  basis 

F2  Provide  for  cold  start  of  one  host  while  the  Test 
Bed  is  running  on  other  hosts 
F3  Report  completion  of  cold  start  of  isolated  host 
to  the  User  Interface  and  to  the  Test  Bed 
operating  system  [System  operator  only] 

F4  Test  Bed  host  restart  cam  be  initiated  from: 

a.  The  host  terminals  (privileged  function) 

b.  The  IISS  terminals  (privileged  functions) 
(Future) 

F5  Reset  status  information 

C4.5.4  Test  Bed  Selective  Host  Drop  Off 

FI  Provide  for  termination  of  Test  Bed  services  on  a 
host  by  host  basis 

F2  Test  Bed  shutdown  is  initiated  either  from: 

a.  The  host  terminals  (privileged  function) 

b.  The  Test  Bed  terminals  (privileged  function) 
(Future) 

F3  Selective  host  drop  off  is  orderly  and  graceful, 
without  loss  of  user  data  [except  abnormal 
shutdowns ] 

F4  The  selective  shutdown  of  a  host  is  reported  to 
the  User  Interface  and  to  the  Test  Bed  system 
[operator  only] 

C4.5.5  Test  Bed  Back-Up/Restore 

FI  Back-up  facilities  are  provided  for: 

1 .  The  Common  Data  Mode 1 

2.  The  Test  Bed  databases 

3.  The  user  application  process  files 

4.  The  Test  Bed  service  files  (statistics,  audit 
trail,  etc.) 

F2  Back-up  can  be  initiated  from  the  user  interface 
(Future) 
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F5  The  Test  Bed  back-up  facilities  use  existing  host 
and  data  management  system  back-up  facilities 
74  Restore  capabilities  are  provided  for  the  files 
listed  in  FI 

F5  Restore  capabilities  use  the  vendor  supplied 
restore  capabilities 


C4.5.6  Test  Bed  Coordination  and  Control 

FI  Initiate  application  prooess  or  Test  Bed  utility 

1.  Load 

2 .  Execute 

5.  Redirect  I/O 
4.  Abort 

F2  Receive  and  route  messages 
F3  Generate  and  distribute  status  information 
F4  Receive  and  interpret  status  information 
F5  Queue  messages  and  regulate  flow 
F6  Trap  host  operating  system  error  messages  and 
generate  status  information  (Partial) 

F7  Guarantee  delivery  of  messages 

F8  Provide  9  record  application  processes  completion 
status 

F9  Monitor  resource  status.  Obtain  and  provide 
status  information 


C4.8.7  Perform  IISS  Recovery  Operations  (Future) 


FI  Support  manual  and  automatic  initiation  of 
recovery  operat i ons . 

Recovery  scenarios:  TBD .  (Partial  -  Manual) 

F2  Support  system  vide  synchronisation  of 

application  process  logs,  databases  and  Journals 
F5  Report  completion  and  status  of  recovery 
operations 

F4  Coordinate  with  reoovery  facilities  provided  by 
local  host  operating  systems  and  by  local 
database  management  systems 
F5  Support  manual  selection  of  recovery 
synchronisation  point 

F6  Provide  system  wide  sequencing  of  pending 
messages 

F7  Acknowledge  system  wide  synchronisation  points 
F8  Exeoute  system  wide  synchronisation  point 
F9  Involke  and  terminate  IISS  systemwide  Quiet 

Points.  Quiet  Points  nay  be  controlled  by  the 
Test  Bed  Administrator/Operator  or  by  a  Test  Bed 
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program. 

F10  Define  other  recovery  functions  to  be  supported 
by  the  systen. 

R5  Maintain  Test  Bed  Systen  Control  Information 

C5.1  Centralised  System  and  Common  Data  Control 

FI  The  information  required  to  control  systen  and 
common  data  is  centrally  maintained  and 
controlled  (Partial  -  System  data  is 
distributed) 

F2  Access  to  the  Common  Data  Model  is  controlled 

F3  Information  contained  in  the  Common  data  Model 
may  be  distributed  to  improve  performance 
(Future) 

F4  Versions  of  the  Common  Data  Model  are  supported 
(Future) 

F5  The  Common  Data  Model  can  be  backed-up  and 
restored 

C5.2  Controlled  Access  of  Systems  and  Common  Data  Control 
Information 

FI  The  description  of  Common  Data  is  protected  and 
is  supplied  to  authorized  users  only 

F2  Common  Data  Model  processor  supports  asynchronous 
processing  environment 

F3  The  Common  Data  Model  supports  error  processing 

F4  The  Common  Data  Model  supports  multiple  user 

processing 

F5  The  Common  Data  Model  acknowledges  all  requests, 
either  with  data  or  status  information 

C5.3  Flexibility  of  the  Common  Data  Control  Structure 

FI  The  Common  Data  Model  can  describe  a  wide  variety 
of  data  structures 

F2  The  Common  Data  Model  can  be  expanded  without 
disrupting  Test  Bed  services 

CS.4  Test  Bed  System  Control  Migration 

FI  The  structure  of  the  Test  Bed  system  control 
information  allows  migration  to  a  back  end 
database  machine 

C5.5  The  Maintenance  of  the  Test  Bed  Control  Information  is 

Computer  Assisted 
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FI  Interactive  aainten&nce  of  the  Conon  Data  Model 
and  Systen  Control  Information 
F2  Computer  assisted  maintenance  of  the  Common  Data 
Model  and  data  includes:  oreation,  deletion, 
updating,  editing 

FS  Provide  meohanism6  to  verify  the  validity  of  the 
Common  Data  Model .  The  mechanisms  to  be  provided 
must  allow  mechanisation  of  their  implementation 
F4  Provide  listings  of  the  Common  Data  Model 
F5  The  effectivity  of  update  versions  of  the  Common 
Data  Model  is  controlled  by  the  Common  Data 
Administrator 

C5.6  A  Common  Data  Model  Supports  the  System  and  Common 
Data  Control  Information 

FI  The  Common  Data  Model  defines  the  entity  o lasses 
and  relations  among  them 
F2  Mappings  between  entity  classes  and  their 
attribute  olasses 

F3  Constraints  defining  permissible  values  for 
attributes 

F4  The  Common  Data  Model  contains  the  syntax  and 
semantics  of  the  user  form  entries  (Future) 

F5  The  Common  Data  Model  contains  help  data 

F6  The  Common  Data  Model  oontains  pre-defined  forms 

(Future) 

F7  The  Common  Data  Model  contains  a  description  of 
the  Test  Bed  Network  (Future) 

F8  The  Common  Data  Model  contains  the  virtual 
terminal  data  (Future) 

R6  Provide  Capability  to  Implement  and  Test  Programs  on  the 

Test  Bed 

06. 1  Protect  System  from  New  Application  Programs 

FI  During  testing,  application  programs  are 

prevented  from  changing  system  data  (Future) 

06.2  Provide  Real  Data  for  Testing 

FI  Application  programs  under  test  may  use  real  data 
for  input 

F2  Application  programs  under  test  are  prevented 
from  updating  the  Test  Bed  databases  (Future) 
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7S  Application  programs  under  test  direct  their 
output  to  a  test  database  or  terminal  (Future) 

F4  Application  programs  are  declared  in  test  node 
via  the  Coaaon  Data  Model  by  its  Administrator 
(Future) 

5  Make  Maximum  Use  of  Vendor  Supplied  Utilities 

FI  Maximum  use  is  made  of  Vendor  supplied  utilities 
for  process  implementation  and  testing 

4  Allow  Analysis  of  Message  Journals 

FI  Message  journals  can  be  sorted  by  source, 
destination  and  by  message  type 
F2  Sorted  message  journals  can  be  output  to  a 
terminal  selected  by  the  user 
F3  Sorted  message  journals  are  cleared  at  the  option 
of  the  user 

5  Test  Bed  May  Be  Shutdown  for  Special  Conditions 
Mo  functional  requirements  identified 

6  Test  Results  Shall  be  Accessible 
See  06. 2  -  F3 

7  Tests  Shall  be  Repeatable 

FI  Copies  of  system  databases  can  be  created  to 
provide  stable  test  data  for  test  purposes 
F2  The  system  database  copies  are  created  at  the 
request  of  the  U6er  (Partial) 

F3  The  system  database  copies  are  released  at  the 
request  of  the  user  (Partial) 

F4  The  system  database  copies  can  be  write  protected 
(Partial ) 

F5  The  version  of  the  Common  Data  Model  being  used 
is  accessible  to  the  user  (Future) 

8  Test  Protection  Modes  Shall  be  Easily  Changeable 
(Future) 

FI  The  test  protection  modes  are  settable  via  the 
CDM 

F2  The  test  protection  modes  include:  write 
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protection  of  output,  redirection  of  output  to  a 
test  output  file,  or  to  the  test  input  file  (in 
the  oase  of  an  input/output  file) 

75  Test  protection  nodes  say  be  declared  without 

recompiling  the  programs  under  te6t  [Test  mode 
requires  program  recompilation] 

3.5.2  Physical /Performance  Requirements 

3.3.2. 1  Physical  Requirements 

To  satisfy  the  requirements  levied  against  the  Test  Bed, 
three  host  computers  must  be  interconnected  via  a  Local  Area 
network.  The  host  computers  are: 

e  VAX  11/780 

e  Honeywell  Level  6 

e  IBM  3033  (or  30xx) 

The  Test  Bed  system  and  application  processes  must  be 
controlled  from  a  single  terminal.  The  early  implementation 
relies  on  VT-100  terminals  for  demonstration  purposes.  In 
keeping  with  the  concept  of  the  Virtual  Terminal  described  in 
this  document,  none  of  the  application  processes  or  Test  Bed 
system  utilities  is  relying  on  the  non-standard  (as  defined  in 
the  Test  Bed)  hardware  features  provided  by  the  VT-100. 

3. 3. 2. 2  Performance  Requirements 

The  Test  Bed  is  experimental  in  nature,  and  its  expected 
level  of  performance  cannot  be  quantified.  Careful  design 
trade-offs  are  made  to  minimise  user  responses  and  elapsed  time. 

To  allow  optimisation  and  experimentation,  a  number  of  Test 
Bed  processing  features  (message  logging,  for  example)  are 
settable  at  the  system  level  via  the  Common  Data  Model .  (Future) 

Furthermore,  the  Test  Bed  design  allows  for  improving 
performance  through  reconfiguration  of  the  hardware  and 
software.  The  portability  of  the  application  processes 
facilitate  reconfiguration. 
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3.5.3  Interfaces  :  Requirements 

3.3.3. 1  Test  Bed  User  Interface 

The  user  interfaces  with  the  Test  Bed  via  the  User 
Interface.  The  functional  requi resents  of  the  User  Interface 
have  been  described  in  Subseotion  R2,  "Provide  Couon  User 
Interface  to  Mew  or  Existing  application  processes".  The  user 
interfaces  with  the  Test  Bed  via  a  terminal.  The  early 
implementation  Test  Bed  accommodates  DEC  VT-100  terminals. 

There  are  no  additional  hardware  interface  requirements.  The 
data  supplied  by  the  user  are  either  system  oommands  or 
application  process  commands  data.  The  nature  and  syntax  of 
the  system  oommands  are  to  be  deoided.  On  the  other  hand,  the 
nature  and  syntax  of  the  existing  application  prooess  oommands 
and  data  is  already  defined  and  will  not  be  modified. 

3 . 3 . 3 . 2  Common  Data  Model  Administrator 


The  Common  Data  Model  Administrator  is  entrusted  with  the 
definition  and  population  of  the  Test  Bed  Common  Data  Model. 

The  Administrator  interfaces  with  the  Test  Bed  Common  Data 
through  a  terminal,  and  exercises  administrative  utilities  which 
have  been  described  functionally  in  Subseotion  3.3.1.  The 
method  of  interaction  of  the  CDM  Administrator  and  the  CDM  is 
TBD.  It  is  anticipated  that  the  CDM  Administrator  performs  the 
majority  of  his/her  work  interactively. 

3. 3. 3. 3  Application  Subsystem  Interfaces 

Specifio  interface  programs  are  used  to  interface  selected 
application  processes  to  the  Test  Bed.  These  programs  are  using 
data  provided  by  the  Common  Data  Model  to  control  the  data 
brought  into  the  Test  Bed.  From  a  hardware  point  of  view,  the 
interfacing  is  implemented  via  magnetic  tapes,  disk  drives,  or 
ASCII  communication  lines.  The  exact  format,  encoding  of  the 
common  data  required  by  the  interface  programs  is  entirely 
dependent  upon  the  application  processes  whioh  are  interfaced. 
Henoe.  the  Test  Bed  must  support  the  transfer  of  binary 
information. 

3.3.4  Technology  Voids 

In  the  context  of  this  system  specifications,  technology 
voids  (TV's)  are  those  activities  which  present  significant 
challenges  from  a  technology  or  implementation  point  of  view. 
These  activities  are  listed  here  because  of  their  impact  on  the 
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completion  of  the  Test  Bed  project. 

5.5.4.1  Communication  Technology 

3. 3. 4. 1.1  Host-to-Host  Cft—iiii<natlon 

TV:  Define  and  inplenent  a  set  of  oonnunication  services  which 
satisfy  the  following  requirements: 

1.  Provide  reliable  host  to  host  oommunioation  servioes. 

2.  Are  iaplenentable,  with  nininun  modifications,  on  the 
VAX  11/780.  the  IBM  3033.  the  Honeywell  Level  6. 

3.  Are  implemented  with  minimum  of  modification  to  the 
Host  Operating  System  and  terminal  drivers. 

4.  Are  iaplenentable  in  a  High  Order  language  (FORTRAN. 
COBOL)  whenever  feasible.  Assembly  language  routines 
nay  be  required. 

5.  Support  communication  protocol  (virtual  circuits  or 
datagrams)  to  be  decided. 

6.  Are  upgradable  to  high  speed  data  transfers. 

7.  Are  modularized  to  oontain  hardware  dependencies. 

8.  Are  control lable  and  manageable. 

3. 3. 4. 1.2  Guaranteed  Delivery 

TV1 :  Define  and  implement  procedures  and  algorithms  required  to 
guarantee  the  delivery  of  messages  within  the  Test  Bed. 
Message  delivery  must  be  guaranteed  even  if  the  destination 
prooess  is  temporarily  unavailable. 

3. 3. 4. 1.3  Process  to  Process  Communication 

TV1:  Define  and  implement  a  set  of  communication  services  which 
satisfy  the  following  requirements: 

1.  Provide  process  to  process  communication  servioes 

2.  Are  implementable,  with  minimum  modifications,  on  the 
VAX  11/780.  the  IBM  3033.  the  Honeywell  Level  6 
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S.  Are  inplenentable  on  the  various  Host  Operating  Systens 
without  Modifications  to  the  host  OS  (other  than  I/O 
drivers) 

4.  Are  callable  fro*  FORTRAN  and  Cobol  programs 

3. 3.4. 2  IISS  S ys ten  Control 


3. 3.4.2. 1  Svsten  Control  Strategy 

TV1:  Define  and  inplenent  a  Systen  Control  Strategy  which 
provides : 

1.  Message  and  application  process  control 

2.  Deadlock  prevention 

3.  Systen  quiet  point 

I 

4.  Coordination  of  connands.  status  and  responses 

5.  Hardware  resource  status  acquisition 

6.  Guaranteed  delivery  of  Messages 

3. 3. 4. 2. 2  Systen  Restart/Recovery 

TV1 :  Define  and  inplenent  the  procedures  required  to  provide  a 
coordinated  and  synchronized  restart  of  the  Test  Bed. 
Procedures  support: 

1.  Execution  of  synchronization  point 

2.  Roll  back  to  synchronization  point 

3.  Orderly  restart  of  Test  Bed  services 

4.  Synchronization  of  application  process  logs 

5.  Systen  status  broadcasting 

3. 3. 4. 2. 3  Databases  Recovery 

TV1 :  Define  and  inplenent  the  procedures  required  to  support  the 
recovery/ synchronization  of  the  Test  Bed  data.  Procedures 
support : 
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1.  Synchronisation  of  databases  with  application  process 
logs  and  application  prooess  queues  on  the  saae  node. 

2.  Synchronisation  of  databases  application  prooess  logs 
and  application  prooess  queues  at  the  systea  level. 

3.3.4.S  Scheaa  Definition 

3. 3. 4. 3.1  Conceptual  Scheaa  Definition  and  Storage 

TV1 :  Define  the  techniques  and  procedures  to  be  used  to  create 
an  integrated  conceptual  scheaa  froa  existing  application 
scheaas . 

TV2 :  Define  and  iapleaent  procedures  to  support  the  definition 
effort  of  a  conceptual  scheaa. 

TV3:  Define  a  aethodology  to  show  a  conceptual  scheaa  in  a 

aachine  useable  fora.  This  definition  of  the  conceptual 
scheaa  supports  the  description  of  the  entities,  relation 
aaong  entities  and  their  attributes,  range  of  allowable 
values  for  the  attributes. 

This  aethodology  is  sufficiently  flexible  to  describe  the 
data  structures  which  can  be  supported  on  CODASYL  database 
aanagers,  and  allows  for  the  description  of  data  with  synonyns, 
hoaonyas,  scale  differences,  structural  differences,  and 
abstraction  differences. 

3 . 3 . 4 . 3 . 2  Def ine  a  Distributed  Scheaa  Architecture 


TV1 :  Define  a  scheaa  architecture  that  extends  the  benefits  of 
the  GODASYL  three  scheaa  architecture  to  the  distributed 
environaent . 

3. 3. 4. 3. 3  Define  Scheaa  Mapping  Trans foraat ions 

TV1 :  Define  the  trans foraat ions  required  to  support  the  scheaa 
architecture  defined  in  3. 3. 4. 3. 2. 

To  be  practical,  these  trans foraat ions  aust  be  coaputer 
inpie  ■entable,  and  be  non-aabiguous . 

Ideally,  the  transforaations  are  perforaed  froa  data 
provided  by: 

1.  The  various  schemas  defined  in  3. 3. 4. 3. 2. 
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2.  The  oonoeplual  schema  defined  in  3.3.4.S.I. 

These  transformations  take  into  account  homonyms,  synonyms, 
and  various  machine  representation  of  the  data. 

3. 3.4.4  Neutral  Data  Manipulation  Language 

TV1 :  Define  and  implement  system  wide  data  manipulation 

primitives  allowing  the  definition  of  set  oriented  data 
manipulation  operations  which  satisfy  the  following 
requirements : 

1.  Non-navi gat ional 

2.  Extendable  to  the  ad-hoc  query  environment 

3.  Selection,  join,  project  capabilities 

4.  Programmer  friendly  non-procedural 

5.  Predefined  error  message  specifications 

3. 3. 4. 5  Data  Retrieval  Operation 

3 . 3 . 4 . 5 . 1  Happing  of  Data  From  Single  Off-Node  database 


TV1 :  Define  and  implement  the  data  mapping  algorithms  required 
to  transmit  data  to  a  requesting  program  from  a  single, 
off-node  database.  The  mapping  algorithms  must  take  into 
account  the  differences  in  schemas,  and  data 
characteristics  which  may  exist  between  the  database  and 
the  application  program  requesting  the  data. 

3 . 3 . 4 . 5 . 2  Happing  of  Data  From  Multiple  Off -Node  databases 

TV1 :  Define  and  implement  the  data  mapping  algorithms  required 
to  transmit  data  to  a  requesting  program  from  multiple 
off-node  databases.  The  mapping  algorithms  must  take  into 
account  the  differences  in  schemas,  data  characteristics 
which  may  exist  between  the  databases,  and  the  application 
program  requesting  the  data. 

TV2:  Define  and  implement  the  procedures  and  algorithms  required 
to  aggregate  the  data  provided  by  multiple  off-node 
databases  into  a  single  data  packet  useable  by  the 
requesting  program.  Support  adequate  level  of  error 
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processing  to  detect  and  flag  possible  errors  occurring  in 
the  various  databases.  Status  information  will  be  provided 
to  the  requesting  application  prooess. 

5.S.4.5.3  Data  Constraint  Checking 


TV1 :  Define  and  implement  the  strategy  used  to  provide  data 

constraint  checking.  This  strategy  reflects  concerns  for: 

1.  Overall  data  integrity 

2.  Ease  of  implementation 

3.  Overall  system  throughput 


The  data  required  to  support  the  data  constraint  checking 
is  supplied  by  the  Common  Data  Model. 


TV2 :  Data  Constraint  checking  is  selectable.  The  mechanisms 
responsible  for  the  selection  and  implementation  of  the 
data  constraint  checks  must  be  identified. 


3. 3. 4. 6  Automatic  Translation  of  Data  Manipulation  Statements 


TV1 :  Define  and  demonstrate  the  algorithms  and  procedures 
required  to  support  the  automatic  translation  of  data 
manipulation  statements  into  procedures  targeted  toward  a 
single  CODASYL  database  manager.  The  translation 
algorithms  must  be  practical  and  capable  of  accommodating 
the  data  structures  defined  by  the  various  schemas. 
Adequate  level  of  error  processing  must  be  provided. 


TV2 :  Define  and  demonstrate  the  algorithms  and  procedures 
required  to  support  the  automatic  translation  of  data 
manipulation  statement  into  procedures  targeted  toward 
multiple  CODASYL  database  managers.  The  translation 
algorithms  must  be  practical,  capable  of  accommodating  the 
data  structure,  defined  by  the  various  schemas,  and  provide 
the  information  required  to  control  the  aggregation  of  the 
data  retrieval  operations.  An  adequate  level  of  error 
processing  must  be  provided. 

3. 3. 4. 7  User  Interface  Command  Form  Processor 

TV1 :  Define  and  implement  a  command  form  processor  sufficiently 
flexible  to  allow  for  the  definition  of  command  menus  and 
command  semantics  in  tables. 
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5.3.5  Data  Requirements 

3.5.5. 1  Logical  Organization  of  Static  System  Data 

The  static  system  data  is  the  data  used  for  reference 
during  operations.  It  characterizes  systen  parameters  and 
attributes. 

The  following  classes  of  system  parameters,  attributes  and 
information  included  in  the  statio  systen  data: 

1.  Schema  definitions 

2.  Message  definition 

3 .  Screen  data 

4.  User  description 

5.  network  description 

6.  Virtual  terminal  data 

7.  User  command  language  syntax  and  semantics 

The  static  system  data  used  to  describe  the  Test  Bed  is 
contained  and  defined  in  the  Common  Data  Model.  This  data  is 
declared  and  updated  by  the  Common  Data  Model  Administrator. 

The  static  system  data  may  be  distributed  by  the  Common 
Data  Model  Processor  to  Improve  performance  or  to  reduce 
software  complexity. 

3. 3. 5. 1.1  Schema  Definition 

The  Test  Bed  uses  a  three  schema  architecture  to  facilitate 
integration.  The  schema  definition  data  allows  the  definition 
of  the  schemas  and  of  the  implied  relationship  existing  between 
the  various  schema  types  existing  in  the  Test  Bed. 

The  following  data  is  required  to  define  the  schemas  of  the 
Test  Bed: 

•  Entity  class  description  (Neutral  Conceptual) 


•  Attribute  class 
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•  Entity /at tribute  relationship 

•  Entity/entity  relationships 

•  Attribute  donain  description 

•  Key.  inherited  key  classes 

e  Entity  class  description  (Meutral  External) 
e  External /conceptual  attributes  relationships 
e  External  schema  access  authorisation 
e  Conceptual /internal  schena  representation 
e  Entity  class  description  (Internal) 
e  Pathing  assertions 

The  above  listed  data  aust  be  obtained  to  support  the  Test 
Bed  demonstration  scenarios. 

3. 3. 5. 1.2  Message  Definition 

Test  Bed  message  headers  contain  information  that  reflects 
the  characteristics  of  the  Test  Bed.  This  information  is 
obtained  from  the  Common  Data  Model.  [System  Data  is  not  in  CDM] 

e  Message  routing  information 

e  Message  delivery,  acknowledgement,  processing 
requirements 

•  Message  priority  and  trigger  information  (initiator, 
receiver) 

•  Message  type 

•  Message  data  access  requirements 

3. 3. 5. 1.3  Soreen  Data  Definition 

The  Test  Bed  user  screens  are  defined  at  the  system  level 
The  following  information  is  required: 
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•  Screen  naae 

•  Screen  security  data 

e  Screen  constant  paraneters  (text,  eto.) 
e  Screen  data  i tens  are  derived  from  the  conceptual  scheaa 

5. 3.5. 1.4  Test  Bed  User  Definition 

The  following  information  is  used  to  define  the  Test  Bed 

user: 

e  User  naae.  password 
e  Legal  user  roles 

e  User  role  privileges  acoess  to  Application  and  System 
utilities 

3. 3. 5. 1.5  network  Description 

The  Hetwork  description  data  defines  the  configuration  of 
the  Local  Area  network,  the  location  of  System  Services  (CDM), 
and  of  the  application  processes. 

The  following  data  is  required  to  describe  the  Test  Bed 
network : 

e  Local  Area  network  configuration  data  (terminals, 
hardware ,  prot oco 1 ) 

•  Host  on  which  Test  Bed  System  Services  resides 
e  Host  on  which  Test  Bed  Application  Subsystems 
e  Host  system  description 

3. 3. 5. 1.6  Virtual  Terminal  Description 

The  Virtual  Terminal  interface  requires  a  description  of 
the  real  terminal  or  application  program  with  which  it 
interfaces.  This  description  is  provided  by  the  Common  Data 
Model  and  defines: 

•  The  features  supported  by  the  real  terminal 
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•  The  character  set  of  the  real  terminal 

e  The  communication  protocol 

3. 3. 5. 1.7  User  Command  Menas  and  S*»*«tloB 

The  syntax  and  semantics  of  the  user  oonaand  menus  is 
defined  in  the  Common  Data  Model.  The  following  information  is 
required:  [Future  -  System  Data  is  not  in  CDM] 

•  User  command  menus 

•  User  command  semantics 

•  User  command  seourity  data 

•  User  Interface  help  messages 

3. 3. 5. 2  Logical  Organisation  of  Dynamic  Input  Data 

The  Test  Bed  dynamic  input  data  falls  into  three  broad 
classes : 

1 .  User  Test  Bed  System  Commands 

2.  User  application  process  commands 

3.  User  application  process  data 

For  existing  subsystems,  the  structure,  syntax  of  the 
subsystem  commands  and  data  is  already  in  place,  and  is  outside 
of  the  soope  of  the  Test  Bed. 

For  new  application  subsystems,  the  structure  of  the 
subsystem  commands  will  be  identical  to  the  organisation  of  the 
Test  Bed  commands,  and  share  the  same  implementation  and  syntax. 

The  organization  of  new  application  subsys terns  input  data 
is  not  defined  at  this  time.  It  must  conform  to  the  Test  Bed 
standards . 

The  organization  and  syntax  of  the  Test  Bed  commands  is  to 
be  decided.  It  is  known  that  the  Test  Bed  commands  will  provide 
an  expert  and  novice  mode  of  operation,  and  will  interface  with 
a  system  wide  Help  Facility. 

It  is  desirable  that  system  commands  be  entered  either  from 


3-32 


V.V.' 


SRD620 140000 
1  Movember  1985 


a  file  or  interactively  fro»  a  terninal . 

S.S.5.5  Logical  Organisation  of  Dynamic  Output  Data 

The  dynamic  output  data  which  a  user  nay  either  receive  or 
select  while  interacting  with  the  Test  Bed  falls  into  four  broad 
classes: 

1.  Test  Bed  systen  service  nodule  acknowledgement  to  user 
commands 

2.  Host  operating  systen  error /status  messages 

3.  Application  process  error/status  messages 

4.  Application  process  output  data 

As  an  enhancement,  the  user  may  select  to  direct  all  four 
classes  of  output  data  to  the  same  device,  or  may  elect  to 
direct  the  application  process  output  data  to  a  distinct  device. 
This  capability  prevents  the  other  classes  of  output  data  from 
garbling  the  output  data  generated  by  the  application  processes. 
(Partial) 

The  Test  Bed  user  thus  is  able  to  direct  output  data 
classes  1  through  3  to  either  a  terminal  or  to  a  file  of  his 
choice.  Likewise,  he  may  direct  the  output  of  an  application 
process  to  a  terminal  or  to  a  file  of  his  own  choice.  (Future) 

3. 3. 5. 4  Internally  Generated  Data 

The  information  internally  generated  by  the  Test  Bed  falls 
into  four  broad  classes: 

1.  Status  information  supporting  the  internal  management 
of  the  Test  Bed 

2.  Statistics  gathered  on  the  usage  of  resources  and 
response  time 

3.  Error  messages  (application  process  and  Test  Bed 
Services) 

4.  Audit  trails 

The  experimental  nature  of  the  Test  Bed  emphasises  the 
importance  of  this  internally  generated  data. 
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This  data  is  stored  in  separate  files,  with  sufficient 
supporting  infornation  to  facilitate  interpretation. 

The  Test  Bed  error  messages  are  displayed  on  the  user 
selected  device  (terainal,  file)  are  simultaneously  logged  on 
the  Test  Bed  systea  error  file. 

The  above  classes  of  Internally  generated  infornation  can 
be  accessed  and  cleared  by  authorised  users.  The  infornation  is 
displayed  on  a  device  selected  by  the  user. 


5.4  Quality  Assurance 

The  Quality  Assurance  and  Configuration  Management 
activities  take  place  during  all  phases  of  the  Test  Bed 
development,  beginning  with  Requirement  Engineering  and  ending 
with  Integration.  Documentation  is  viewed  as  an  integral  part 
of  the  development  process  rather  than  an  add-on  phase  to  the 
development  cycle. 

3.4.1  Requirement  Engineering  Phase 

The  requirement  engineering  phase  of  a  project  is 
important.  It  must  be  conducted  thoroughly,  with  method  to 
ensure  that  the  product  being  specified  and  design  meets  the 
goals  of  the  customer. 

The  outputs  of  the  Requirement  Engineering  phase  of  the 
Test  Bed  project  are: 

1.  Systea  Meeds  Analysis  document 

2.  Systea  Requirements  document 


3.  Systea  Specification  document 

Generation  of  the  documents:  General  Electric  is  responsible  for 
the  production  of  the  above  documents;  SofTech,  CDC,  and  other 
contractors  as  listed  in  the  Preface,  support  GE  in  this  effort 
by  supplying  specific  inputs  and  documents.  A  formal  review  is 
conducted  jointly  by  General  Electric  and  its  subcontractors. 


I CAM  program  office  reviews :  The  above  documents  are  reviewed  by 
the  ICAM  program  office,  who  nay  request  modifications  required 
to  better  serve  its  General  Electric  and  its  subcontractor  shall 
respond  to  the  request  for  modifications  by  amending,  when 
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possible,  the  original  documents.  This  cycle  Is  repeated  until 
the  program  office  is  satisfied  that  the  Test  Bed,  as  specified, 
will  meet  the  Air  Foroe  needs. 

Conf iguration  Management:  Once  the  above  documents  have  been 
reviewed  and  have  been  accepted  by  the  Air  Foroe,  the  documents 
are  placed  under  configuration  management  control  with  Systran, 
the  I CAM  Librarian.  The  documents  are  promptly  distributed  to 
any  subsequent  effort.  The  documents,  onoe  under  configuration 
management  control,  can  no  longer  be  changed  oasually.  Changes 
must  be  made  through  the  Change  Control  function. 

Change  Control  Function:  Requests  for  changes  are  reviewed  by 
General  Electric  and  its  subcontractors  for  feasibility  and 
impact  on  cost  and  schedule.  Requests  may  be  formulated  by  the 
I CAM  program  office.  General  Electric  and  its  subcontractors. 
Requests  for  changes  that  are  approved  for  implementation  are 
documented  at  the  appropriate  level  and  placed  under 
configuration  management  control.  The  existing  documents  and 
resulting  amendments  form  a  new  base  line  on  which  any 
subsequent  effort  is  based.  The  new  base  line  is  promptly 
distributed  to  all  parties. 

Review  Mechanisms :  The  review  of  the  documents  produced  during 
the  Requirement  Engineering  phase  is  facilitated  by  the 
meticulous  and  exacting  traceability  provided  in  the  documents 
themselves. 

Review  Procedure :  The  chief  objective  of  the  reviews  conducted 
of  the  documents  produced  during  the  Requirement  Engineering 
phase  is  to  ensure  congruence  of  the  Test  Bed  features  and  of 
the  Air  Force  Meeds.  The  review  is  facilitated  by  the 
meticulous  and  exacting  traceability  built  into  the  documents. 
Each  function  must  be  traceable  to  a  needs  expressed  by  the  Air 
Force.  As  the  specification  and  design  progress,  the  review 
must  focus  on  the  soundness  of  the  technical  approaches  proposed 
in  support  of  the  Air  Force  needs.  Specification  validation  by 
inspection  is  the  main  procedure  used  to  carry  out  such  reviews. 

3.4.2  Design  and  Implementation  Phase 

The  Test  Bed  is  designed  and  implemented  using  the 
documents  produced  during  the  Requirement  Engineering  phase  as  a 
base  line.  Recall  that  these  documents  have  been  reviewed  and 
validated  by  inspection  and  are  under  Configuration  Management 
oontrol . 
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The  documents  produoed  during  the  Design  and  Inpl ementat I on 
phase  are: 

1.  System  Design  Specif i oat ion 

2.  System  Test  Plan 

3.  Development  Specifications 

4.  Product  Specification  -  as  designed 

5.  Product  Specification  -  as  built 

6.  Unit  Test  Plan 

7.  System  Test  Plan 

8.  System  Test  Report 

9.  Users  Manuals 

Documents  1  through  4  benefit  from  the  review  procedure 
used  in  the  Requirement  Engineering  phase. 

Item  8  is  generated  by  walking  through  the  programs  written 
to  support  the  implementation  of  Item  4.  These  walk  throughs 
are  conducted  by  people  other  than  the  programmers  responsible 
for  writing  the  programs.  This  accepted  approach  eliminates  the 
well  known  psychological  obstacles  whioh  surface  when  a 
programmer  is  asked  to  criticise  his  or  her  own  work. 

The  Product  Specification  -  as  built  -  and  the  software  it 
describes  are  jointly  placed  under  configuration  control. 
Modifications  to  either  one  requires  invoking  the  ohange 
management  procedures. 

Unit  Testing  is  conducted  by  the  application  programmers, 
since  independent  testing,  although  desirable,  is  a  very  costly 
procedure.  The  Unit  Test  Plan,  is  however,  generated  Jointly  by 
the  programmer  and  the  Quality  Assuranee  Engineer. 

System  Testing  is  conducted  under  the  direction  of  the 
System  Engineer  with  support  from  the  Quality  Engineer. 

3.4.3  Test  Bed  Software  Quality  Attributes 

The  quality  of  software  can  be  described  in  terms  of 
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quality  factors  which  are  aission  dependent.  Bearing  in  aind 
the  experiaental  and  changing  nature  of  the  Test  Bed  software, 
it  is  required  that  the  Test  Bed  Software  be: 

1.  Traceable 

2.  Coaplete 

S.  Consistent 

4 .  Accurate 

5.  Staple 

6.  Modular 

7 .  General 

8 .  Expandable 

9.  Systea  software  Independent 

10.  Machine  independent 

11.  Terainal  independence 

12.  Use  coaaon  data  definitions 

13.  Database  aanageaent  systea  independent 

The  above  criteria  will  be  used  when  reviewing  software  as 
well  as  when  uaking  the  unavoidable  engineering  trade-offs 
facing  designers.  Efficiency,  although  desirable,  is  not 
thought  to  be  of  sufficient  concern  to  override  the  above  listed 
quality  criteria. 
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APPEMDII  A 

TEST  BED  SEEDS  AM ALTS IS 


A. 1  Background  Information 

The  Meeds  Analysis  presented  in  this  Section  i6  founded  on 
the  following  documents . 

1 .  “The  Integrated  Sheet  Metal  Center" 

Source:  I CAM  Program  Offioe 

Date:  SO  September  81 

Document  Mnemonic:  ISMC 

2.  "Meeds  Issues"  Documents 

Source:  Richard  Mayer 
Date:  8-9  March  82 

Document  Mnemonio:  MEEDS 

3.  "Memorandum  For  The  Record” 

Source :  Mathan  Tupper 
Date:  5  October  81 

Document  Mnemonic:  MEMO 

A. ii  Meeds  Analysis  Methodology 

End  User  and  System  Meeds  definition.  The  above  documents 
have  been  reviewed  for  their  need6  oontents.  The  explicit  and 
implied  needs  contained  in  these  documents  have  been  extracted 
and  referenced  to  form  the  Test  Bed  Meeds  Analysis  Document. 

The  Test  Bed  Meeds  Analysis  Document  and  the  documents  prepared 
for  the  I CAM  program  office,  such  as  the  CBIS  Heeds  Analysis, 
state  of  the  art.  and  requirement  documents,  form  the  basis  on 
which  the  Test  Bed  requirement  document  will  be  prepared.. 

A . 1  Mission  Statement 


In  the  following,  needs  are  listed  and  explained,  then  & 
reference  is  given  to  one  of  the  documents  listed  in  section  A.i 
above  (i.e.,  ISMC,  Meeds,  or  MEMO)  where  the  need  is  found. 

A. l.l  To  Develop  and  Demonstrate  Integration  Technology 

A. 1.1.1  To  Systematically  Develop  Combination  of  Technologies 

Systematically  develop  combination  of  technologies  required 
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to  solve  the  Information  System  Integration  problem. 

(ISMC.  III,  17) 

A. 1.1. 2  To  Provide  Visibility  iato  Cost  and  Problems  of 
Integration 

Provide  visibility  into  the  oost  and  problems  associated 
with  doing  integration  (at  least  in  a  test  environment). 

(Seeds.  B.  ii) 

A. 1.1. 5  To  Demonstrate  the  Flexibility  of  the  Integration 
Environment 

The  need  to  propose  and  demonstrate  advanced  information 
system  development  concepts  (a  la  system  development  thread) 

(not  how  you  do  it  neoessarily  but  how  flexible  is  the  resulting 
environment  to  ohange). 

(Heeds.  A) 

A. 1.1. 4  To  Demonstrate  Advanoed  Concepts  in  Information 
Management 

The  need  to  propose  and  demonstrate  advanoed  concepts  in 
information  management  (a  la  the  Information  Management  Thread) 

(Meeds.  A.  iv) 

A. 1.1. 5  To  Demonstrate  that  Integration  is  Workable  in  an 
Evolutionary  Mode 

The  solution  must  be  workable  in  current  environments.  It 
must  also  support  an  evolutionary  implementation  of  the  new 
Information  Management  Thread  (IMT)  technology  into  the  existing 
hardware,  software  and  particularly  the  management  systems  of 
these  environments. 


(ISMC.  III.  17) 

A. 1.2  To  Support  the  2201  Contractor  in  the  Implementation  of 
the  ISMC 

A. 1.2.1  To  Support  the  2201  W  2202  Development  and 
Implementation 

A-2 
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Establish  a  center  of  excellence  and  a  cadre  of  experienced 
I CAM  companies  personnel  to  support  2201  conoept  development  and 
2202  implementation. 


(Needs.  B.  i) 

A. 1.2. 2  To  Simplify  the  Task  of  the  2201  Contractor  in 
Integrating  other  I CAM  Subsystems 

. . .Thereby  considerably  reducing  the  risk  to  the  successful 
2201  contractor.  ....  and  shortening  the  lead  time  for 
implementation  of  the  ISMC. 

(Memo,  page  1.  paragraph  2) 

A. 1.2. 3  To  Validate  System  before  Implementation  on  the  ISMC 

(6201)  is  to  be  a  Test  Bed  for  Information  Management 
System  concepts,  for  individual  advanced  manufacturing  systems, 
and  for  the  initial  integration  of  two  or  more  systems.  The 
intent  is  that  all  such  systems  (or  at  least  most  of  them)  will 
be  run  through  the  Test  Bed  before  implementation  in  the  ISMC. 

(Memo,  page  1,  paragraph  2) 

A. 1.2. 4  To  Identify,  to  Quantify  Initial  Performance 
Improvements 


Such  a  Test  Bed  will  identify  and  solve  problems,  as  well 
as  demonstrate  and  quantify  initial  performance  improvements. 

( Memo ,  page  1 ,  paragraph  2 ) 

A. 1.3  To  Support  the  ICAM  Program  Activities 


A. 1.3.1  To  Provide  a  Proof  of  Tangible  Benefits  by  Early  83 

The  solution  strategy  must  provide  proof  of  tangible 
benefits  by  early\1983  in  order  to  assist  in  transferring  these 
concepts  into  the  ISMC  demonstration. 

(ISMC,  III,  17) 


A. 1.3. 2  To  Demonstrate  Integration  of  Manufacturing 
Appl  i cat  ions 

The  need  to  demonstrate  integration  of  manufacturing 
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applications . 


(Meeds,  A,  ii) 

A. 1 .3.5  To  Demonstrate  Major  Steps  in  Long  Range  Paperless 
Factory  ~ 

A. 1.3. 4  To  Demonstrate  I CAM  Software  Viability 

The  Meed  to  Demonstrate  I CAM  Software  Viability. 

(Meeds,  A,  i) 

A. 1.3. 5  To  Run  I CAM  Systens  on  Test  Bed  Before  Inplenentation 

A  potential  user  (of  I CAM  Systems)  will  never  be  the  first 
user  of  any  ICAM  product  run  through  the  Test  Bed  even  if 

something  ( . )  is  not  used  in  the  ISMC,  it  still  will  have 

been  integrated  into  and  demonstrated  in  the  Test  Bed. 

(Memo,  page  1,  paragraph  2) 

A. 1.3. 6  To  Provide  a  Second  Verification  and  Validation  to  the 
ICAM  Software 

Get  a  second  opinion  of  ICAM  developed  software 
systems . (a\backdoor\approach  to  V0V) 

(Meeds,  B,  ill) 

A. 1.3. 7  To  Educate  the  ICAM  Community  to  the  Total  ICAM  Picture 

Educate  the  Program  Office  and  the  ICAM  community  to  the 
total  picture. 


(Meeds,  B,  iv) 

A. 1.4  To  Support  the  Following  High  Level  Meeds  of  the  Air 
Foroe 


The  Air  Force  "needs"  those  needs  associated  with  improving 
our  defense  posture. 


(Needs.  D) 
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A. 1.4.1  To  Reduce  Weapons  Cost 

(Needs,  D,  i) 

A. 1.4. 2  To  Increase  Surge  Capability 

(Needs,  D,  11) 

A. 1.4. 3  To  Improve  Planning  Capability 

(Needs,  D,  ill) 

A. 1.4. 4  To  Improve  Capabilities  of  Defense  Contractors 

(Needs,  D.  iv) 

A. 1.5  To  Support  the  Following  High  Level  Needs  of  the 
Aerospace  Industry 

Manufacturing  “needs"  those  needs  associated  with  improving 
productivity  through  the  systematic  application  of  SDH  and 
computer  technology. 

(Needs,  C) 

A. 1.5.1  To  Increase  Profits 

(Needs,  C,  i) 

A. 1.5. 2  To  Improve  Responsiveness 

To  improve  responsiveness  to  change  in: 

1.  Order  timing,  quantity  or  configuration 

2.  Engineering 

3.  Technology 

(Needs,  C,  ii) 

A. 1.5. 3  To  Improve  Product  Quality 

(Needs,  C,  iii) 


A. 1.5. 4  To  Improve  Schedule  Realization 
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(Meeds,  C,  lv) 

A. 1.5. 5  To  Improve  Competitive  Position 

(Meeds,  C.  v) 

MOTS:  "The  following  scenarios  are  listed  here  because  the  Test 
Bed,  per  Mission  Statement  A. 1.5  supports  the  ISMC 
implementation  and  development.  These  scenarios  shed  additional 
light  on  the  requirements  which  must  be  satisfied  by  the  Test 
Bed  to  be  of  value  to  ISMC” . 

A. 2  ISMC  Scenarios 

A. 2.1  Product  Engineering  Meeds 


A. 2. 1.1  To  Provide  for  Manufacturing  Engineering  to  Review 
Designs 


To  provide  for  manufacturing  engineering  to  review  designs 
and  design  changes  for  produclbility  prior  to  release  of  firm 
design. 

A. 2. 1.2  To  Provide  for  Coordination  of  Engineering  Changes 

To  provide  for  coordination  of  engineering  changes  with  all 
affected  activities  prior  to  release  to  determine  impacts  of 
engineering  changes  on  schedule,  costs... 


A. 2. 1.3  To  Establish  Effectiveness  Basd  on 


?e  of  Change 


To  establish  effectiveness  based  on  type  of  change,  cost  of 
retrofit,  versus  co6t  of  production  installation,  availability 
of  new  parts  and  customer  requirements. 

A. 2. 1.4  To  Withdraw  am  Old  Bill  of  Material 

To  withdraw  an  old  bill  of  material  and  insert  a  new  bill 
of  material  on  a  net  change  basis. 

(ISMC,  III,  5) 

A. 2. 2  Manufacturing  Engineering  Meeds 

A. 2. 2.1  To  Provide  History  of  the  Activities 


To  provide  a  history  of  the  activities  which  led  to  the 
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design  of  the  center,  including  alternatives  considered  or 
rejected. 

(ISMC,  III,  7) 

A. 2. 2. 2  To  Provide  a  Description.  In  Detail 

To  provide  a  description,  in  detail,  of  the  operating 
strategy  (or  strategies)  for  the  proposed  center,  including  the 
strategies  to  control  and  handle  material  and  tools  in  the 
material  handling  systen,  and  strategies  for  aaohine  tool 
processing  and  quality  control. 

(ISMC,  III.  7) 

A. 2. 2. 3  To  Conduct  Appropriate  Simulations 

Appropriate  simulations  of  the  proposed  center  and  elements 
of  it  which  address  systen  configuration,  operating  strategies, 
parts  spectrum  and  perfornance  measures.  The  performance 
■easures  to  be  addressed  should  include  at  least  the  direct  and 
indirect  hours  of  personnel,  scrap  hours,  throughput 
time,  machine  utilization,  span  tine,  queue  time,  jobs 
completion  route,  number  of  late/expedited  jobs. 

(ISMC.  III.  7) 

A. 2. 2. 4  To  Consider  Those  Automation  Priorities  Defined  in  2103 

In  addition,  the  design  of  ISMC  shall  consider  those 
automation  opportunities  identified  in  I CAM  Project  Priorities 
2103,  2108,  9104  and  9301. 

(ISMC,  III,  7) 

A. 2. 3  Process  Planning  Meeds 

A. 2. 3.1  To  Provide  Direct  Access  to  Logical  Data 

The  ISMC  must  contain  an  interface  to  the  Process  Planning 
activity  of  the  technical  thread  to  provide  direct  access  and 
transfer  of  the  logical  data  generated  in  Process  Planning. 


(ISMC,  III,  8) 
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A. 2. 5. 2  To  Provide  Automation  Comaun 1 oat 1 on  to  Create  Work 
Instructions 


It  is  required  that  the  capability  exist  for  automated 
commun 1 cat i on ,  storage  and  retrieval  of  the  appropriate 
information  in  order  to  create  work  instructions  for  the  shop 
floor. 


(ISMC,  III.  8) 

A. 2. 3. 5  To  Structure  and  to  Store  Process  Planning  Data 

Process  Planning  data  aust  be  structured  and  stored  to 
support  the  operation  of  numerical  control  processes  by  on-line 
communication  of  information  to  numerical  controlled  processes 
and  control  functions. 

(ISMC.  III.  9) 

A. 2.4  Master  Schedule  Planning  Heeds 

A. 2. 4.1  To  Simulate  the  Effects  of  Proposed  Changes  on 
Production  Resources 

I  The  Master  Schedule  Planning  activity  shall  have  the 

|  capability  to  simulate  the  effects  on  production  resources. 

I  including  machine  types,  personnel,  inventory  levels,  of 

!  proposed  changes  in  the  production  schedule  or  product  mix. 

|  (ISMC.  III.  9) 

I 

i  A. 2. 4. 2  To  Load  and  to  Execute  Simulation  in  Batch  Mode 

S  The  simulation  can  be  loaded  and  executed  in  a  batch  mode. 

(  provided  that  on-line  access  to  such  information  as  Schedules, 

i  current  resources  status . .  can  be  accomplished. 

(ISMC,  III.  9) 

A. 2. 4. 3  To  Receive  the  Indentured  Bill  of  Material  from 
Manufacturing  Planning 

Production  Requirements  Planning  from  Manufacturing 
Planning  and  Process  Planning,  it  receives  the  manufacturing 
indentured  bill  of  material,  and  information  regarding  set-up 
time,  run  time  per  piece,  and  material  move  time. 
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(ISMC,  III.  10) 

A. 2. 4. 4  To  Retrieve  Reoent  Actual  Mamufaicturing  Statistics 

There  &  significant  variance  exists.  Production 
Requirements  Planning  could  then  examine  the  factors  on  which 
the  foreoast  was  made  (such  as  set-up  tine,  run  tine,  scrappage 
and  the  like),  call  up  the  recent  actual  data  on  these  factors, 
and  update  where  necessary  the  planning  faotor6  using  reoent 
actual  data. 


(ISMC.  Ill,  10) 


A. 2. 5  Capacity  Planning 

A. 2. 5.1  To  Access  Automatical ly  the  Inventory  Requirement  Files 
To  include  the  following  (minimum)  capabilities: 


1.  Automatically  access  inventory  requirements  files  and 
process  planning  files  and  then  convert  production 
requirements  into  loads  on  production  resources. 

2.  Automatically  generate  requirements  for  personnel. 

3.  Automatically  identify  overload  conditions  at  the 
available  resource  level. 


4.  Provide  capability  to  interactively  evaluate 

alternatives  ( . )  for  resolving  overload  conditions. 

(ISMC,  III,  11) 


A. 2. 5. 2  To  Retrieve  Automatically  the  Inventory  Requirements 


As  a  minimum  Capacity  Planning  must  have  a  capability  which 
provides  the  automatic  retrieval  of  inventory  requirements  and 
process  planning  data  needed  to  convert  production  requirements 
into  loads  on  production  resources. 


(ISMC,  III,  11) 


A. 2. 6  Production  Facilities  Loading  Needs 

A. 2. 6.1  To  Access  Automatically  the  Tool  and  Material  Files 
To  Include  the  Following  (Minimum)  Capabilities: 
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As  a  minimum  the  capability  is  required  to: 

1.  Automatically  verify  availability  of  tools  and 
materials  for  each  production  order,  and  generate 
shortage  list. 

2.  Automatically  call  for  delivery  of  required  tools  and 
materials  when  seleoted  load  is  released  to  the 
dispatch  function. 

3.  Automatically  generate  initial  shop  floor  load  based  on 
inventory  requirements  and  tool /material  availability. 

4.  Automatically  Identify  bottleneck  conditions  of 
individual  resources . 

5.  Provide  for  interactive  intervention  to  undo 
bottlenecks,  or  to  maintain  full  loading  of  resources 
which  are  of  high  value. 

6.  Provide  simulation  capability  for  use  in  interactive 
intervention. 


(ISMC.  Ill,  12) 

A. 2. 7  Dispatch  Load  Needs 

A. 2. 7.1  To  Maintain.  On  Line,  the  Following  Information 

The  following  information  required  for  this  decision  must 
be  stored  on  line  with  real-time  access. 

1.  Set-up  and  run  tine  for  eaoh  machine  C . ) 

2.  Status  of  each  machine,  automatically  incorporated  into 
history  files  (loaded  with  operator  ID,  out  of  service, 
current  set-up  -  with  code  or  other  ID.  availability, 
and  any  other  machine  data  required). 

3.  Operator(s)  available. 


(ISMC,  III,  12) 
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A. 2. 7. 2  To  Perform  the  Dispatch  Function  ManuaHj  or 
Automatically 

The  dispatch  function  can  be  either  automatic  or  manual ,  a 
simulation/optimization  capability  to  assist  in  assigning  jobs 
and  operators  to  machines  required  for  either  approach. 

(ISMC,  III.  12) 

A. 2. 7. 3  To  Access  Automatically  Prooess  Performance  Data 

To  Maintain  the  Following  (Minimum)  Information: 

The  following  information  is  required  as  a  minimum 

1.  Actual  set-up  and  run  times,  machine  used,  operator, 

and  disposition  of  output.  ( . ) 

2.  Amount  and  cause  of  down  time  for  each  machine. 

( . ) 

3.  Amount  of  maintenance  performed  on  each  machine. 

4.  Time  spent  with  no  work  assigned  to  each  machine. 

5.  Any  "significant"  performance  among  operators. 

(ISMC,  III,  13) 

A. 2. 7. 4  To  Agglomerate  the  Above  Information 

(The  above  information)  must  be  amendable  to  agglomeration 
in  order  to  arrive  at  appropriate  performance  data  across  the 
entire  center,  e.g.  total  span  time  for  a  specific  order  across 
the  center. 

(ISMC.  III.  13) 


A . 3  Test  Bed  Needs 

A. 3.1  Integration  Needs 

A. 3. 1.1  Integration  Demonstration  Needs 


1.  The  ISMC  is  intended  to  demonstrate  the  validity  of  the 
basic  ICAM  concept.  Integration  as  well  as  to  show 
specific  payoffs  resulting  from  incorporating  various 
tools  to  affect  integration. 
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(I SMC.  III.  2) 

2.  Demons t rating  various  systems  engineering  tools  and 
techniques  in  the  design  and  oonstruotion  of  a  truly 
integrated  center  is  equally  important. 

(ISMC.  III.  2) 

3.  The  key  oonoept  being  demonstrated  is  integration. 

(ISMC.  II.  3) 

A. 3. 1.2  Integration  Definition 

Everyone  using  a  piece  of  data.... is  exactly  using  the  same 
data,  and  further  that  the  data  is  accurate  at  the  time  it  is 
used. 


(ISMC.  II.  3) 

A. 3. 1.3  Integration  Scope 

It  has  proven  helpful  to  consider  responsiveness  to  change 
and  integration  from  the  viewpoint  of  4  major  groups  or  threads 
of  functions. 


A. 3. 


1.  Product  Technology 

2.  Control 

3.  Information  Management 

4.  System  Development 

1 .4  Excessive  Data  Redundancy: 
Excessive  Redundancy  of  Data  Exists 


(ISMC,  III.  13) 

A. 3. 2  Interfacing  Meeds 

A. 3. 2.1  Interfacing  Stand  Alone  CAD  9  CAM  Systems 

Interfacing  stand  alone  CAD  9  CAM  systems.  It  is  desirable 
that  this  CAD/CAM  interface  be  made  automatic. 
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(XSMC.  XXX.  6) 

A. 3. 2. 2  Interfacing  Standards 

Recommendations  regarding  interface  standards  and  the  use 
and  integration  of  nanufaoturing  applications  programs  such  as 
process  planning  and  Manufacturing  oontrol  language  program 
generation  should  be  considered. 

(XSMC,  XXX.  6) 

A. 3. 2. 3  Interface  to  Process  Planning 

The  I SMC  must  contain  an  interface  to  the  Prooes6  Planning 
activity  of  the  technical  thread  to  provide  direct  acoess  and 
transfer  of  the  logical  data  generated  in  Process  Planning. 

(ISMC.  III.  5) 

A. 3. 2. 4  Machine  to  Maohine  Interface  Problems 

Machine  to  machine  interface  problems  are  encountered  in 
some  type  of  data  transfers.  Programs,  user  and  system  messages 
transactions  (Application  Processes),  data  elements  and  files 
must  be  transferable  between  similar  or  unlike  processors. 

(ISMC,  III,  14) 

A. 3. 3  Data  Management  Heeds 

A. 3. 3.1  Data  Structuring  Needs 

1.  It  is  required  that  the  process  plan  database 
information  be  structured  and  stored  to  provide  access 
and  retrieval  of  those  process  plans  having  specific 
characteristics . 

(ISMC,  III.  8) 

2.  Process  Planning  data  must  be  structured  and  stored  to 
support  the  operation  of  numerical  control  processes  by 
on-line  communication  of  Information  to  numerical 
controlled  processes  and  control  functions. 


(ISMC.  Ill,  9) 
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S.  Data  used  by  the  app 11 oat ions  must  oonfora  to  a  set  of 
standards  and  structure  to  be  defined  prior  to  the 
detailed  design  of  the  applications. 

(ISMC.  III.  22) 

A.S.S.2  Data  Portability  Meeds 

Installations  are  tied  to  a  particular  vendor's  data 
support  systea  which  dictates  and  generally  restricts  the  range 
of  options  for  data  structuring  and  the  possible  access  aates. 

(ISMC.  III.  15) 

A. 3. 3.5  Data  Validation  Meeds 

There  are  inadequate  facilities  for  enforoenent  of 
constraint  checks  during  initial  entry  of  data. 

(ISMC.  HI.  15) 

A. 3. 3. 4  Data  Integrity  Meeds 

Data  is  inaccurate  and  untiaely  because  it  is  not  collected 
at  the  source. 

(ISMC,  III,  15) 

A. 3. 3. 5  Data  Redundancy  Eliaination  Needs 

Eliaination  of  Data  Duplication  Needs  Excessive  Redundancy 
if  Data  Exists. 

(ISMC,  III,  15) 

A. 3. 3. 6  Tiae  Dependency  of  Data  Needs 


Most  systens  have  inadequate  provision  for  retention  and 
control  of  tiae  dependent  versions  of  data. 

(ISMC,  III,  15) 

A. 3. 3. 7  Data  Security  Meeds 

Tight  security  over  peralssion  to  access  and  update  data  is 
not  generally  provided  in  today's  system. 
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(ISMC,  III.  15) 

A. 9. 3. 8  Active  Data  Dictionary  Weeds 

Most  data  dictionaries  are  not  comprehensive.  They  do  not 
include  all  the  relevant  entity  and  attribute  classes.  They 
tend  to  be  used  as  static  repositories  of  documentary 
information  rather  than  as  dynamic  mechanisms  used  in  the  actual 
accessing  and  processing  of  data. 

(ISMC,  III.  15) 

A. 3. 4  Distributed  Database  Meeds 


A. 3. 4.1  Distributed  Databases 

Concept  explicitly  set  forth  in  Figure  2,  Figure  3,  and 
Figure  4  appearing  in  ISMC  pages  21.  23.  24. 

A. 3.4.2  Database  CODASYL  Compatibility  Meeds 

Database  management  systems  used  by  the  ISMC  applications 
are  assumed  to  be  CODASYL  compatible. 

(ISMC.  III.  22) 

A. 3. 4. 3  Individual  Database  Recovery  and  Backup  Meeds 

Individual  database  Recovery  and  Backup  Meeds  providing  for 
concurrent  updating,  standard  data  integrity,  security,  and 
backup/ recovery  capabilities. 

(ISMC,  III.  22) 

A. 3. 5  Heterogeneous  Hardware  Heeds 

A. 3. 5.1  Multiprocessor  Heterogeneous  Hardware  Meeds 

A  heterogeneous  processing  environment,  with  some 
processors  being  transactions  oriented  and  others  supporting 
primarily  batch  or  mixed  batch  and  on-line  interactive 
applications  can  be  supported. 


(ISMC,  III,  22) 
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A. 5. 5. 2  Back -end  Database  Machine  Heeds 

A  baek-end  database  computer  or  “ Intel ligent*  disc  drives 
could  also  be  incorporated  at  this  level  (ISMC  Mid  Level)  to 
iaprove  performance. 

(ISMC,  III,  24) 

A.S.5.3  Local  Area  Hetwork  Heeds 

The  local  area  network  (single  continuous  cable  or 
interconnected  bus  or  ring  architecture)  and  adoption  of  a 
standard  protocol  facilitate  the  faster  acoess  to  all  types  of 
data. 


(ISMC,  III.  22) 

“Figure  3  and  Figure  4  exhibit  local  area  networks*. 

A. 3. 5. 4  Local  Area  network  Standard! gat ion  8  Planning  Meeds 

Lack  of  overall  planning  and  mangement  in  the  building  of 
couun i cat i on  networks  leads  to  capacity  problems, 
incompatibilities  between  equipment  thus  requiring  interface 
“kludges” . 

(ISMC,  III,  14) 

A. 3. 5. 5  Local  Area  Metwork  Expansibility  Meeds 

Inflexibility  in  types  of  equipment  which  can  be  supported, 
and  inability  to  upgrade  to  more  powerful  units  or  to  make  use 
of  new  technologies  as  they  become  available. 

(ISMC,  III,  14) 

A. 3.6  Common  Data  Control  Meeds 


A. 3. 6.1  System  Psable  Directory  of  Network  Characteristics 
Meeds 


Most  organizations  do  not  maintain  an  on-line  system 
usable  definition  and  directory  of  network  characteristics. 
(Capabilities  and  protocols  of  each  node;  primary  and  alternate 
access  paths). 


(ISMC,  III,  14) 
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A. 5. 6. 2  System  Usable  Directory  Meeds 

Most  organizations  do  not  Maintain  an  on-line  system 
usable  definition/directory  of  network  characteristics. 
(Capabilities  and  protocols  of  each  node;  pr inary  and  alternate 
access  paths); 


(ISMC,  III.  14) 

A. 3. 6. 3  System  Psable  Location  Directory  Heeds 

(Most  organizations  do  not  maintain  of  A. 3.6.2)  security 
information  about  legal  users;  legal  transactions  (Application 
Processes)  by  node;  location  directory  for  programs  and  data, 
etc.)  thus  preventing  adequate  management  and  control  of  the 
system  . . . 


(ISMC,  III.  14) 

A. 3. 6. 4  Comprehensive  Data  Dictionary  Meeds 

Most  data  dictionaries  are  not  comprehensive.  They  do  not 
include  all  relevant  entity  and  attribute  classes. 

(ISMC,  III,  15) 

A. 3. 6. 5  Active  Data  Dictionary  Meeds 

(Data  dictionaries)  tend  to  be  used  as  static  repositories 
of  documentary  information  rather  than  as  dynamic  mechanisms 
used  in  the  actual  accessing  and  processing  of  data. 

(ISMC,  III.  15) 

A. 3.6.6  ISMC  Common  Data  Meeds  (Min  Configuration) 

Additional  information  defined  and  brought  under 
centralized  control  includes:  location  of  data,  data 
relationships,  some  data  constraints,  protocols  and  definition 
of  all  "common"  data  used  by  ISMC  applications. 

(ISMC,  III.  22) 


A . 3 . 6 . 7  ISMC  Common  Data  Definition  Meeds 

(ISMC)  Common  data  is  defined  as  (1)  data  used  by  more  than 
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one  individual,  or  (2)  data  updated  by  one  and  used  by  another 
or  (5)  data  planned  to  evolve  into  a  category  described  in 
criteria  (1)  or  (2)  above  or  (4)  any  data  which  affects 
information  in  the  above  categories. 

(ISMC.  III.  22) 

A.S.6.8  ISMC  Connon  Data  Weeds  (Max  Configuration) 

Information  about  the  linkages  of  documentation, 
procedures,  programs,  soreen  formats,  reports,  user  roles  and 
responsibilities,  support  personnel  roles,  standards  and 
guidelines  are  all  maintained  within  the  system  and  can  be 
used  as  needed  to  control  various  functions. 

(ISMC,  III.  24) 

A. 3.6.9  ISMC  Improved  Constraint  Checking  of  Common  Data  (Max) 

ISMC  Common  Data  Growth  Version  Meeds  (Max  Configuration) 

Improved  constraint  checking  will  be  provided  such 
capabilities  as  condition  ohecking  on  existence.  non\existenoe, 
or  specific  values  of  elements  related  to  incoming  transaction 
(Message),  in  addition  to  the  standard  constraint  checking  of 
the  values  of  the  transaction  (Message)  parameters. 

(ISMC.  Ill,  24) 

A. 3. 7  User  Interface  Heeds 

A. 3. 7.1  User  Interface  Consistency  Meeds 

Independently  developed  applications  and  system  utility 
programs  lack  consistency  in  format,  command  interpretation  menu 
presentation  and  handling,  user  prompting,  lead  through,  error 
diagnostic  messages,  etc. 

(ISMC,  III,  13) 

A. 3. 7. 2  Users  Interface  Flexibility  Meeds 

Systems  are  frequently  inflexible  and  difficult  to  change. 
Users  cannot  get  rapid  response  to  changing  requirements  for 
information  and  are  dependent  upon  the  data  processing  staff  for 
all  changes. 
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(ISMC,  III.  14) 

A.S.7.S  Standard  Query/ Re port  Generator  Heeds  (Min) 

A  standard  query/report  generator  language  would  be 
desirable  (in  the  Min  ISMC  configuration). 

(ISMC.  III.  24) 

A. 3.7.4  Pser  Co— and  Language  Heeds 

User  Conaand  Language  Heeds  (Mid  82)  and  the  User  Conaand 
Language(s)  aust  be  defined  and  developed  by  Mid  82. 

(ISMC.  III.  24) 

A. 3. 7. 5  Standard  User  Interface  Heeds  (Mid  Configuration) 

A  standard  User  Interface  is  provided  to  insure  consistency 
in  user  interaction,  to  provide  for  standard  aenu  presentation 
and  handling,  user  help  facilities,  novioe/expert  aode  of 
interaction,  standard  diagnostic  aessages,  aocess  to  standard 
utility  packages,  etc. 


(ISMC.  Ill,  24) 

A . 3 . 7 . 6  User  Ad-Hoc  Queries  Heeds  (Min  Configuration) 

Ad-hoc  queries  and  data  retrieval  across  applications  can 
be  provided  with  this  configuration.  The  local  area  network 
(....)  and  adoption  of  a  standard  protocol  facilitate  the  faster 
access  to  all  types  of  data  in  the  systen. 

(ISMC,  III.  22) 


A. 3.8  Simulation  Heeds 

> 

A . 3 . 8 . 1  Manufacturing  Planning  Simulation  Heed* 

(3)  Appropriate  Sinulations  of  the  proposed  center  and 
elenents  of  it  which  address  systen  configuration,  operating 
strategies,  parts  spectrun,  and  performance  measures. 


(ISMC,  III.  7) 


SRD620 140000 
1  November  1985 


A. 5. 8. 2  Master  Schednle  Planning  Simulation  Meeds 

The  Master  Schedule  Planning  activity  shall  have  the 
capability  to  simulate  the  effects  on  production  resources, 
including  aachine  types,  personnel,  and  Inventory  levels  of 
proposed  changes  in  the  production  schedule  or  product  nix. 

(ISMC,  III,  9) 

A. 3. 8. 3  Siaulatlon  Batch  Run  Meeds 

This  siaulation  can  be  loaded  and  executed  in  batch  node, 
provided  that  such  inforaation  as  schedules,  ourrent  resources, 

. . . ,  sped  tiaes  can  be  executed. 

(ISMC,  III,  9) 

A. 3. 8. 4  Siaulation  Iapleaentation:  IDSS  Meeds 

“The  ISMC  is  using  the  siaulation  capabilities  contained  in 
IDSS.  This  is  evidenced  on  Figures  2,  3,  8  4  of  the  ISMC 
docuaent " . 


.  as  supported  by  appropriate  tools  froa  IDSS,  all 

running  on\an\ information  management  system  similar  in 
capability  to  the  "mid"  configuration . 

(Memo,  p  1,  pp  3) 


A. 3. 9  Processing  Heeds 

A. 3. 9.1  Database  Updating  Needs  (Min) 

At  this  level,  the  application  programs  still  control 
actual  updating  of  the  data. 

(ISMC,  III,  22) 

A. 3. 9. 2  Database  Updating  Needs  (Mid) 

The  IISS  will  have  complete  responsibility  for  the 
integrity  of  the  data  under  its  control,  all  updating  will  be 
handled  by  it  rather  than  by  application  programs. 


(ISMC,  III,  24) 
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A. 5. 0.5  Transaction  and  Batoh  Processing  Weeds  (Min) 

A  heterogeneous  processing  envlronnent .  with  sose 
processors  being  transaction  oriented  and  others  supporting 
primarily  batoh  or  nixed  batoh  and  on-line  interactive 
applications  can  be  supported. 

(ISMC,  III.  22) 

A. 5. 0.4  Transaction  Prioritisation  Meeds 

Lack  of  dynamic  change  capability  for  transaction 
(Application  Process)  priorities. 

(ISMC.  III.  16) 

A. 3. 9. 5  Processor  Load  Leveling  Meeds  (Max  Configuration) 

An  overall  automatic  network  manager  is  needed  to  handle 
load  leveling  across  multiple  systems.  Typioally,  load  leveling 
is  a  manual  function,  handled  by  system  support  personnel;  thus 
it  cannot  respond  to  dynamically  ohanging  loads. 

(ISMC,  III.  16) 

A  network  management  facility  which  has  the  capability  to 
provide  some  measure  of  load  leveling  on  processors,  provision 
of  alternate  routes  to  data  sources  sued  to  user  device. 

(ISMC.  III.  24) 

A. 3. 10  Response  Time  Heeds 

A. 3. 10.1  Immediate  Retrieval  of  Engineering  Changes  Needs 

Further,  it  is  essential  that  the  complete  status  of  any 
engineering  change  be  immediately  retrievable,  such  that 
affected  activities  can  coordinate  their  operations  with  the 
progress  and  effects  of  change. 

(ISMC,  III.  6) 

A. 3. 10.2  Eight  Hour  Retrieval  of  Engineering  Change  Preparation 
Data  Needs 


To  support  engineering  change  preparation  and  other  design 
activities  the  following  data  sets  must  be  maintained  in  a 
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manner  such  that  the  most  current  version  of  the  information  can 
be  accessed  within  a  reasonable  tine,  such  as  eight  (8)  hours. 

CISMC.  III.  6) 

A.S.ll  Test  Bed  Resource  Usage  Statistics  Meeds 

Performance  measurement  and  optimisation  problems  are 
related  to  the  lack  of  procedures  and  mechanisms  for  the 
collection  and  analysis  of  system  usage  and  performance 
statistics  and  the  lack  of  automated  techniques  for  controlling 
Cor  assisting  the  decision-maker  responsible  for  controlling) 
distribution  of  processing,  distribution  of  data,  communication 
system  load  leveling,  etc. 

(ISMC,  III,  17) 

A. 3. 12  Standards  and  Procedures 

A. 3. 12.1  Test  Bed  Development  Standard  Meeds 

Standards  for  ICAM  applications  (development)  (languages, 
module  size  limits,  structured  techniques,  system  interface 
rules)  must  be  maintained  also. 

(ISMC,  III,  22) 

A. 3. 12.2  Test  Bed  Application  Standard  Heeds 

Standards  which  must  be  utilized  in  this  level  of 
implementation  include:  DBMS  characteristics,  data  dictionary, 
communication  protocols,  the  data  structure  definition  (format 
and  content ) . 

(ISMC,  III,  22) 

A. 3. 12.3  Test  Bed  Layering  Standard  Needs 

Standards  dealing  with  architecture  layering  to  provide  for 
the  many  types  of  device  and  data  independence  refined  to  in 
Section  A. 3. A  must  also  be  defined  to  facilitate  upgrading  the 
system  and  to  promote  flexibility  and  responsiveness  to  change. 


(ISMC,  III,  24) 
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A. 4  Project  Drivers 

A. 4.1  Responsiveness  to  Change  Meeds 

A. 4. 1.1  Responsiveness  to  Changes  in  Applications  Meeds 

A  mandatory  aspect  of  the  ISMC,  then,  is  that  all  aspects 
of  it  be  designed  for  ease  of  change.  The  changes  can  be  of 
several  types,  for  example: 

1.  Adding  shop  floor  processes,  both  numbers  and  types 

2.  Replacing  one  manufacturing  system  with  another,  which 
does  the  same  function,  for  example,  replacing  a 
computer  aided  order  release  system  with  one  which  is 
fully  automated,  and 

3.  Integrating  additional  manufacturing  systems  with  the 
ISMC. 


(ISMC.  II,  2) 

It  has  proven  helpful  to  consider  responsiveness  to  change 
and  integration  from  the  viewpoint  of  four  (4)  major  groups  or 
thread  functions.  These  are: 


1 . 

Product  technology 

2. 

Control 

3. 

Information  management 

4. 

System  development 

(ISMC,  III, 

3) 

.2 

Responsiveness  to  Change 

in  Data  Needs 

Systems  are  frequently  inflexible  and  difficult  to  change. 
Users  cannot  get  rapid  response  to  changing  requirements  for 
information  and  are  dependent  upon  the  data  processing  staff  for 
al 1  changes . 


(ISMC,  III,  14) 
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A.4.1.S  Responsiveness  to  Change  In  Equipment  and  Technology 
Meeds 


Inflexibility  in  types  of  equipment  which  can  be  supported, 
and  inability  to  upgrade  to  more  powerful  units  or  to  sake  ubc 
of  new  technologies  as  they  become  available. 

(ISMC.  III.  14) 

A. 4. 1.4  Responsiveness  to  Mew  Data  Processing  Technology  Meeds 

The  solution  must  be  receptive  to  new  information 
processing  technologies. 

(ISMC,  III,  17) 

A. 4. 1.5  Layered  Architecture  Meeds 

This  implies  an  appropriately  layered  architecture  which 
will  allow  any  layer  to  be  replaced  by  an  equivalent  until 
interchangeable/replaceable  IR  parts)  with  minimal  disruption  to 
he  adjacent  layers. 


(ISMC,  III,  17) 

A. 4. 2  Portability  Meeds 

A. 4. 2.1  Decoupling  Logical  and  Physical  Data  Structure  Meeds 

Most  systems  tie  logical  and  physical  definitions  of  the 
data  structure  together  in  an  inflexible  manner.  Whenever  the 
physical  organization  of  the  data  needs  to  be  changed  (for 
performance  reasons  or  to  support  new  types  of  data),  all 
programs  which  reference  the  data  must  be  modified,  recompiled 
and  tested. 

(ISMC,  III.  15) 

A. 4. 2. 2  Eliminating  Program  Peripheral  Dependency  Needs 

Physical  control  mechanisms  for  specific  peripheral  devices 
are  frequently  embedded  in  application  program  logic,  creating 
inflexible,  device  dependent  systems. 

(ISMC,  III,  16) 
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A. 4. 2. 3  Eliminating  Dependency  on  Vendor  Data  S vs tea  Heeds 

Installations  are  tied  to  a  particular  vendor's  data 
support  system  which  dictates  and  generally  restricts  the  range 
of  options  for  data  structuring  and  the  possible  access  modes. 

(ISMC.  III.  15) 

A. 4. 2. 4  Virtual  Terminal  Weeds  (Mid  Configuration) 

...A  "virtual  device  terminal"  intercepts  all  messages  to 
and  from  terminals  and  oonverts  diverse  inooming  characteristics 
into  standard  formats  for  presentation  to  the  application 
software,  and  also  converts  standard  output  from  the 
applications  into  device  specific  formats,  control  characters, 
etc. 


(ISMC.  III. 24) 

A. 4. 2. 5  Migrating  the  IISS  Dictionary  to  Back  End  Machine  Meeds 

A  back  end  database  computer  or  "intelligent”  disc  drives 
could  also  be  incorporated  at  this  level  to  improve  performance. 
The  IISS  dictionary  will  be  more  heavily  used  in  active 
participation  in  processing  all  transactions  (Messages  and 
Application  Processes). 


(ISMC,  III,  24) 

A. 4. 3  Technology  Development  Needs 

A. 4. 3.1  Systematic  Development  of  Integration  Technology  Meeds 

Systematically  develop  and  demonstrate  those  combinations 
of  technologies  as  required  to  solve  the  information  system 
integration  problem. 


(ISMC,  III,  17) 

A. 4. 3. 2  Evolutionary  Technology  Development  Meeds 

The  solution  must  be  workable  in  current  environments.  It 
must  also  support  an  evolutionary  implementation  of  the  new  IMT 
technology  into  the  existing  hardware,  software  and  particularly 
the  management  systems  of  the  environments. 


(ISMC,  III,  17) 
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A. 5  Projeot  Management  Meeds 
A . 5 . 1  Schedule  Meeds 


The  first  Test  Bed  deaonstration  would  occur  by  1  Feb  83 

(Meao,  p  1.  paragraph  3) 

A. 5. 2  Test  Bed  Configuration  Meeds 

It  will  include  the  shop  floor  control  6ysten  fron  6103, 
integrated  with  appropriate  nodules  of  a  ooaaeroially  available 
MRP,  as  supported  by  appropriate  tools  fron  IDSS,  all  running  an 
infornation  nanageaent  systen  sinilar  in  capability  to  the  Mid 
configuration  described  in  our  31  Sept.  81  docuaent. 

A. 5. 3  Test  Bed  Expected  Life  Cycle  Meeds 

The  Test  Bed  is  designed  to  readily  accept  new  nodules  and 
replaoenent  systeas /nodules ,  and  the  current  thinking  is  for  it 
to  reaain  in  operations  into  1986  deaonstrating  new  capabilities 
before  they  are  installed  in  the  ISMC. 

(Meao,  p.  1,  paragraph  3) 

A. 5. 4  Project  Traceability  Meeds 

(Lack  of)  traceability  between  aission  statement  (system 
requirements)  and  the  systen  specification  (exists  and  aust  be 
el iainated) . 


(ISMC.  Ill,  28) 

A. 5. 5  Test  Bed  Affordability  Meeds 

The  solution  strategy  aust  be  affordable  in  a  practical 
sense  by  the  ICAM  Program,  which  lnplles  prioritisation  with 
respect  to  the  key  technical  areas  where  developnent  is 
currently  lacking  in  the  field. 

(ISMC.  III.  17) 

A. 5. 6  Technology  Transfer  to  ISMC  Meeds 


The  solution  strategy  aust  provide  proof  of  tangible 
benefits  by  early  1983  in  order  to  asist  in  transferring  those 
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oonoepts  into  the  ISMC  deaonstration. 

(ISMC,  III,  17) 
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APPEMDI1  B 

TEST  BED  USER  SCEKARIOS  (MAXIMUM 
OOMFIGURATIOM) 


MOTE 


The  scenarios  described  in  this  section  attempt  to  encompass 
foreseeable  use  of  the  Test  Bed.  They  are  provided  as 
background  information  to  guide  the  engineering  decisions  which 
will  be  made  during  the  design  phase  to  ensure  maximum 
flexibility  and  extensibility  of  the  design.  The  extent  of  the 
implementation  of  the  scenarios  described  here  is  dependent  upon 
the  level  of  resources  available  to  the  developers  of  the  Test 
Bed. 
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B.  1  Relationship  Between  the  Test  Bed  and  CBIS 
B.1.1  CBIS  Definition 

CBIS  (Computer  Based  Information  System)  -  A  network  of 
information  processing  resources  and  associated  procedures  that 
enable  Manufacturing  operations  and  management. 

(CBIS  2-1) 

B.1.2  Test  Bed  Definition 


A  network  of  information  processing  resources  and 
associated  procedures  that  enable  demonstration  of  the 
Information  Management  Thread,  as  well  as  demonstration  and 
validation  of  ICAM  Subsystems. 

B.1.3  Discussion 

From  the  above  definitions,  it  follows  that  the  Test  Bed  is 
a  demonstration  CBIS,  hence,  the  Test  Bed  must  satisfy  to  the 
functional  requirements  of  CBIS,  without  satisfying  to  the 
operational  requirement  (number  of  terminals,  availability, 
response  time,  etc.)  of  a  CBIS  sized  to  support  manufacturing 
operations  and  management. 

The  CBIS  class  I  updates  (coordinated  updates,  performed 
directly  on  the  databases  without  involving  existing  application 
programs)  are  excluded  from  the  functionality  of  the  Test  Bed. 
This  exclusion  reflects  the  technical  complexity  and  risk 
implied  by  the  implementation  of  the  class  I  updates. 

B.1.4  Graphic  Representation 

See  Figure  B-l. 

B.2  Test  Bed  User  Classification 

B.2.1  Test  Bed  User  Definition 

To  be  consistent  with  other  technical  documents  related  to 
the  Test  Bed,  the  definition  of  the  Test  Bed  user  includes 
persons,  machines  (terminals  and  real  time  peripherals),  and 
software  modules. 

A  Test  Bed  user  is 
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1.  A  person,  group  of  persons  who  makes  use  of  the 
integrated  features  provided  by  the  Te6t  Bed. 

2.  A  machine  (real  time,  terminal)  which  obtains  or  feeds 
data  to  a  subsystem  integrated  by  the  Test  Bed. 

3.  A  software  module  which  communicates  with  a  subsystem 
integrated  by  the  Test  Bed. 

A  classification  of  the  Test  Bed  users  is  shown  in  Figure 
B-l.  This  figure  illustrates  additional  roles  which  are 
fulfilled  by: 

4.  Persons  who  maintain,  upgrade,  manage  or  demonstrate 
the  integrated  application  subsystems  or  IISS  services 
installed  on  the  Test  Bed. 


5.  Persons  who  generate  and  maintain  the  Test  Bed 
standards . 


B.2.2  Test  Bed  User  Role  Traceability  Matrix 

OSER-ROLES  NEEDS  OR  CBIS  REFERENCES 


End  User 
Person 

A. 3. 7 

A. 3. 10 

Software 

A. 3. 8 

A. 3. 9 

Machine 

Hosts 

A. 3. 5. 1 

A.  4. 23 

CBIS  B2 

Lan 

A. 3. 5. 3 

A. 3. 5. 4 

A. 3. 5. 5 

NC  Machines 

A. 3. 2. 4 

CBIS  A4 . 

7 

Back-End  Data 

A. 3. 5. 2 

A. 4. 2. 5 

Machine 

Terminal 

A. 4. 2. 4 

A. 4. 2. 2 

CBIS  A4.6 

CAD  0  CAM  Systems 

A. 3. 2. 1 

2 .  CDM- 

Admini strator 


A. 4. 1.2  A. 4. 1.3  A. 3. 3  A. 3. 4  A. 3. 6  A. 3.1. 
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USER-ROLES  HEEDS  OR  CBIS  REFERENCES 


3. 

System- 

Administrator 

A. 3. 11 

A. 4. 1.4 

A. 4. 1.5  A. 4.1 

4. 

Appl ication 
Specifier 

A. 4. 1.1 

A. 4. 2.1 

A. 4. 2. 2 

A. 3.2.3 

5. 

IISS  Service 
Specifier 

A. 4. 1.4 

A. 4. 1.5 

A. 4.1 .3 

A. 4. 2.1 

6. 

Program 

Office 

A. 1.1 

A. 1.3 

A. 5 

A. 1 .2.3 

7. 

2201  8  Other 

I  CAM 

Contractors 

A.l  .2 

A. 3.66 

A. 3.68 

A. 3. 69  A. 2.0 

8. 

Test  Developer  A. 4. 3 
(not  User) 

A. 3.1 

A. 5. 4 

9. 

U.S.  Air 

Force 

A. 1.4 

10. 

Aerospace 

Industry 

A.  1 .5 

11  . 

Test  Bed 
Standard  8 
Procedure 
Specifier 

1.3.12 

1 .3.2.2 

12. 

Test  Bed 
Demonstrators 

A.  1 .3.2 

A.  1 .3.3 

A.  1 .3.4 

A.  1 .3.7 

B .  3 

End  User  Functions 

B.3.1  End  User  Definitions 


A  person,  group  or  department,  a  machine  tool,  etc.  which 
performs  a  clearly  defined  manufacturing  function.  The  role 
performed  is  defined  by  the  manufactur ing  organization. 

(CBIS  2-1) 
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B.5.2  End  User  Role 

The  End  User  is  restricted  in  his  usage  of  the  Test  Bed  to 
invoking  any  of  the  following  services: 

1.  Predefined  Application  Processes 

2.  Predefined  Proceedings 

S.  Predefined  Forms,  Help  File 

4.  Available  Systen  Services 

5.  Available  Application  Process  Support  Services 

6.  The  IISS  Ad  Hoc  Query  Language 

7.  The  IISS  User  Command  Language 

The  End  User  plays  a  role  which  is  fundamentally  different 
from  all  other  roles  identified  in  the  Test  Bed.  He  makes  use 
of  application  processes,  procedures  and  services  which  already 
exist . 

The  application  processes,  procedures  and  services  are 
created  for  him  by  the  Test  Bed  Application  Specifiers.  The 
Application  Specifiers  respond  to  the  needs  of  the  the  End  Users 
by  invoking  the  functional  primitives  which  are  provided  by  the 
Test  Bed. 

Although  the  End  User  is  restricted  to  a  predefined  world, 
a  number  of  services  are  provided  to  him.  The  End  User  relies 
on  these  services  to  obtain  information  about  the  status  of  the 
IISS  System. 

B.3.3  End  User  Scenarios 


Thirty-six  (36)  End  User  Scenarios  have  been  identified. 
These  scenarios  which  are  self  explanitory  are  listed  in 
paragraph  B.3.4  where  they  are  correlated  against  the  scenarios 
identified  in  the  CBIS  document  or  in  the  Needs  Analysis 
(Appendix  A). 
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B.3.4  End  User  Scenarios  Traceability  Matrix 


EMD  USER  SCEHARIOS  MEEDS 

1.  Sign  on/sign  off  IISS 

2.  Application  Process 
Directory 
(request  of) 

3.  Request  IISS  Status 


4.  Query  status  of  specific 
application 

process 

5.  Execute  predefined  message  to 
invoke  IISS  application 

6.  Execute  predefined  application 
process  to  query  IISS  data 

(1  or  M  databases,  files) 

7.  Execute  predefined 
appl i cat ion 

process  update  IISS  data 
(1  or  M  databases,  files) 

8.  Execute  predefined  message  to 
cancel  previous  application 
process 

9.  Create  predefined  procedures 
(made  of  predefined  application 
processes) 

10.  Execute  predefined  procedures 

11.  Delete  predefined  procedures 


OR  CBIS  REFEREMCES  PRIORITY 
A. 3. 3.7  A. 3. 11 

A. 3. 7.1 

Verbal  request  from 
Program  Office 

A. 3.9. 3 

A. 3.9. 3  A3.1 

A. 2.0  A3.1 

A. 3. 9.1  A. 3. 9. 2  A3.1 


12.  Send  message  to  IISS  user 

13.  Receive  message  from  IISS  user 

14.  Request  up  load/dovn  load  of  A. 3. 3. 1(6)  CBISA.3.3.7 

binary  data 
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B.S.4  End  User  Scenarios  Traceability  Matrix  (Coat'd) 

PTO  OSER  SCBHARIOS  WEEDS  OR  CBIS  REFERENCES  PRIORITY 


15.  Block  predefined  application 
processes  in  MACRO 

16.  Execute  IISS  help  file 

17.  Request  IISS  file  directory 

A3. 2. 5 

18.  Select  output  device  for  application 
process  procedure 

A3. 2. 7 

A3. 2. 6 

19.  Select  input  device  for  application 
process  procedures 

20.  Select  output  device  for  system 
commands 

A3. 2. 7 

A3. 2. 6 

21.  Modify  application  process  priority 

22.  Modify  own  password 

A. 3. 9. 4 

A. 3. 3.7 

A .  3 . 2 . 

23.  Run  in  batch  node 

24.  Invoke  IISS  query  language 

A. 3. 8. 3 

A. 3. 7. 3 

A. 3. 9. 

25.  Forn  ad  hoc  queries  (read-only) 

26.  Run  ad  hoc  language  help  file 

A. 3. 7. 3 

A. 3. 7. 6 

A3 . 2 . 8 

27.  Define  data  effectivity  date, 

version  number 

28.  Select  novice/expert  user  dialogs 

29.  Select  application  process 

triggering  node 

(immediate,  deferred,  conditional) 

A .  3 . 3 . 6 

A. 3. 7. 5 

CBIS  3-30 

A. 2. 1 .4 

30.  Invoke  predefined  form 

31 .  Invoke  user  command  language  commands 

32.  Define  UCL  command  files 

A. 3. 7. 3 

A. 3. 7. 4 

A. 3. 6. 8 
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EHD  USER  SCENARIOS  HEEDS  OR  CBIS  REFEREHCES  PRIORITY 

3S.  Execute  UCL  oouand  files 
54.  Delete  UCL  command  files 

35.  Invoke  report  generator  A. 3. 7. 3 

36.  Invoke  message  definition  language  A3. 2. 10 

B.4.0  IISS  Services  and  Application  Specifier  Functions 
B.4.1  IISS  Software  Classification 

Figure  B-3  shows  a  taxonomy  of  the  software  run  on  Test 

Bed. 

Figure  B-3  dichotomizes  the  IISS  software  into  two  main 
categories  which 
are: 

1.  IISS  Applications 

2.  IISS  System  Services 

This  classification  leads  to  recognizing  two  classes  of 
IISS  software  specifiers:  The  system  (ISS)  specifier  and  the 
IISS  application  specifier. 


Table  B-l  gives  the  definition  and  examples  of  the  six 
subclasses  of  software  functions  shown  in  Figure  B-3. 

Table  B-2  is  the  IISS  Software  Traceability  Matrix. 


B.4.2  IISS  Subsystem  Specifier  (Application  Specifier) 
Definition 


In  the  above  context,  the  CBIS  definition  of  the 
application  specifier  can  be  retained. 


"The  mechanism  (e.g.,  person)  responsible  for  translating  a 
manufacturing  information  requirement  into  one  or  more  CBIS 
application  processes  which  satisfy  that  requirement.  The 
application  specifier  may  also  be  involved  in  modifying  the 
Neutral  Data  Structure,  if  required. 


(CBIS  2-1) 
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Figure  B-3 .  AO  -  IISS  Software  Classification 
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Figure  B-4.  A1  -  CUM  Servioes 
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TABLE  B-l 

IISS  SOFTWARE  APPLICATIOB  DEVELOPMEBT  DEFIEITIOES  AMD  EXAMPLES 


Stand  Alone 

Defined  as  a  non-updating  program  which  makes  use  of  IISS 
data.  Else  not  within  the  soope  of  IISS. 

Example:  OR  Department  wants  to  make  a  histogram  of  flat 
sheet  metal  part  statistics  by  surface  and  by  thickness. 

2 .  Interfaced  Appl i cat i on 

Defined  as  a  program  which  is  too  specialised  or  too  costly 
to  be  developed,  and  which  must  be  used  as  procured. 
Example:  MRP  as  procured  from  IBM. 

3 .  Integrated  Appl i oat i on 

Defined  as  a  program  which  obtains  some  of  its  input  data 
from  the  IISS  databases  and  which  updates  some  IISS 
database(2) . 

Example:  MC-MM 

Application  Process 

A  process  which  causes  specific  actions  to  be  taken  within 
IISS.  An  application  process  causes  either  one  of  the 
following  to  happen: 

a.  Data  Query  8  Display 

b.  Data  Update 

An  application  process  is  made  up  from  the  IISS  execution 
control  and  data  manipulation.  Application  process 
primitives  supplied  by  the  IISS  system  developer. 

3.  Network  Services 

IISS  services  which  are  made  available  in  a  uniform  fashion 
across  all  nodes. 

Example:  Message  Guaranteed  Delivery 
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TABLE  B-l 

I IBS  SOFTWARE  APPLICATION  DEVELOPMEXT  DEFINITIONS  AND  EXAMPLES 

(Continued) 


6.  DBMS  and  Hardware  Speoifier  IISS  Services 

IISS  servioes  which  interpret  and  respond  to  the  network 
IISS  services.  The  DBMS  and  hardware  specif io  IISS  services 
exist  on  each  node.  These  servioes  are  OS.  hardware.  DBMS 
dependent . 

7.  CDM  Services 

IISS  services  which  provides  CDM  data  to  a  requestor. 
Example:  Message  Validation  Data 
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TABLE  B-2 

TEST  BED  SOFTWARE  CLASSIFICATION  -  TRACEABILITY  MATRIX 


: 


I 


SOFTWARE  CLASS 

REEDS  ARALYSIS  STATEMENTS 

B.1.0 

IISS  Applications 

B.1.1 

Stand  Alone  Application 

Rot  required. 

Mentioned  for  completeness. 

B.1.2 

Interfaces  Application 
Application  Specifier 

IISS  Generalized  Interface 

A. 3. 2. 3 

A. 3.2.2 

B.1.3 

Application  Process 

Data  Manipulation  Procedure 
Execution  Control  Request 

A. 3.9. 3 

A. 3.9. 3 

CBIS  A. 4. 3. 7 

A. 3. 9. 4 

B.1.4 

Integrated  Application 

A. 3. 1.1 

B.2.0 

IISS  Services 

B.2.1  Network  Services 

Ad  Hoc  Query  Language 
Common  Data  Model 
Message  Definition  Language 
Local  Area  Network  Protocols 
Help-Files 

User  Command  Lanaguage 

B.2.2  DBMS  and  Hardware  Specifier 
Services 

Virtual  Terminal  Interface  A. 4. 2. 4 

Application  Execution  Control 

Mechanism 

Data  Manipulation  Mechanism 
Data  Query  Meehan  i cm 

Data  Update  Mechanism  A. 3. 9.1  A. 3.9. 2 


A. 3. 7. 6  A. 3. 7. 3  CBIS  A3. 2. 8 
A. 3. 6 
CBIS  A3. 2 

A. 3. 7. 5 
A. 3. 7. 4 
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B.4.S  IISS  Subsystem  Specifier  (Application  Speoifler)  Role 
B.4.5.1  Application  Specifier  Role  Description 


The  application  specifier  is  charged  with  developing, 
aodifying,  deleting  new  or  existing  IISS  applications  or  IISS 
application  processes. 

While  developing  or  aodifying  an  IISS  application  process, 
the  applloatlon  specifier  aay  be  called  to  specify  or  to 
retrieve  the  aeta-data  contained  in  the  GUI. 

The  application  specifier  develops  new  application 
processes  by  asseabling  existing  systea  services  to  fulfill 
reliably  and  rapidly  the  processing  requireaents  of  a 
aanufacturing  inforaation  application. 

B.4.3.2  Application  Specifier  Won-Role  Description 

It  is  not  the  aission  of  the  application  specifier  to 
develop,  aodify  or  delete  new  or  existing  IISS  services.  These 
activities  are  the  responsibilities  of  the  IISS  service 
developer. 

The  application  specifier  has  the  undisputed  needs  to  have 
access  to  the  CDM  and  has  the  knowledge  required  to  specify  or 
update  eleaents  of  the  CDM.  However,  to  aaintain  centralised 
control  over  the  CDM  it  is  reconaended  that  the  application 
specifier  be  only  authorized  to  make  temporary  changes  to  the 
CDM  for  test  purposes.  The  actual  installation  in  permanent 
fora  of  these  changes  should  only  be  done  by  the  CDM 
Administrator  or  his  deputies. 

B.4.4  IISS  Subsystem  Specifier  (Application  Specifier) 

Scenarios 

1.  Read  only  access  to  the  CDM  to  obtain  the  definition  of 
existing  CDM  data  elements,  procedures,  etc. 

2.  Search  the  CDM  for  the  existence  or  non-existence  of 
specific  data  eleaents,  procedures,  etc. 

3.  Create  temporary  definition  of  future  CDM  elements  for 
test  purpose. 


4.  Recommend  modifications,  update,  deletion,  insertion  of 
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data  elements,  procedures,  files  to  the  CM! 
Administrator . 


5.  Recommend  modifications,  updates,  deletion,  addition  of 
IISS  services  to  the  system  administrator. 

6.  Create,  update  existing  user  forms. 

7.  Recommend  new  or  modified  user  focus  to  the  COM 
Administrator . 

8.  Design,  code,  modify  new  or  existing  application 
programs . 

9.  Design,  code,  modify  new  or  existing  application 
processes . 


10.  Compile,  link  new  or  existing  application  program 
(batch) . 

11.  Compile,  link  new  or  existing  application  processes. 

12.  Test  new  or  modified  application  programs  and 
application  process  on  existing  database.  Inhibit 
update  to  the  IISS  DBMS'  during  testing. 

13.  Install  tested  application  processes  or  procedures  in 
the  Test  Bed  without  Test  Bed  down  time. 

14.  Install  tested  application  program  in  the  Test  Bed 
without  extensive  Test  Bed  down  time. 

15.  Install  tested  forms,  help  file,  new  CDM  application 
processes  anddata  definition  without  Test  Bed  down 
time,  defer  effectivity  until  CDM  Administrator 
review) . 


16.  Create  and  install  the  documentation  of  new  or  modified 
application  processes  in  the  CDM,  without  Test  Bed  down 
time.  Defer  effectivity  until  CDM  Administrator 
approval . 

17.  Upon  request  of  the  CDM  Administrator  remove  existing 
application  programs  and  application  processes  meta 
data  from  the  CDM  without  Test  Bed  down  time. 

18.  Upon  request  of  the  System  Administrator,  remove 
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existing  application  programs  and  application  processes 
from  the  IISS  system,  without  Test  Bed  down  tiae. 

5.5  IISS  Systea  Specifier 

B.5.1  IISS  (Systea)  Services  Specifier  Definition 

Person  responsible  for  specifying,  developing,  aodifying 
doouaenting,  and  testing  new  or  existing  IISS  systea  services. 

B.5.2  IISS  Systea  Service  Specifier  Role 

B.5.2.1  IISS  Systea  Services  Specifier  Role  Descriptions 

The  IISS  systea  services  specifier  specifies,  develops, 
aodifies.  docuaents  and  tests  the  general  purpose  services  aade 
available  by  the  IISS  system  to  the  application  specifier. 

The  IISS  services  can  be  divided  into  two  broad  classes. 

1 .  network  Services 

2.  DBMS  and  Hardware  Specifier  Services 

B.5.2. 2  IISS  Systea  Service  Specifier  Non-Role  Description 

It  is  not  the  mission  of  the  IISS  system  service  specifier 
to  develop,  modify  or  delete  new  or  existing  IISS  application 
programs.  These  activities  are  the  responsibilities  of  the  IISS 
application  specifier. 

Like  the  application  specifier,  the  IISS  system  service 
specifier  has  the  need  to  access  the  CDM  meta  data,  and  has  the 
knowledge  required  to  specify  or  update  elements  of  the  CDM. 
However,  to  maintain  the  centralized  control  over  the  CDM  it  is 
recommended  that  the  system  service  specifier  be  only  authorized 
to  make  temporary  changes  to  the  CDM  for  test  purposes.  The 
actual  installation  in  permanent  form  of  these  changes  should 
only  be  done  by  the  CDM  Administrator  or  his  deputies. 

B.5.3  IISS  System  Service  Specifier  Scenarios 

1.  Read  only  access  to  the  CDM  to  obtain  the  definition  of 
existing  CDM  data  elements,  message  definitions, 
network  resources . 


2.  Search  CDM  for  the  existence/non-existence  of  specific 
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data  element,  procedures,  network  resources. 

5.  Create  temporary  definition  of  future  CDM  elements  for 
test  purposes. 

4.  Recouend  nod if i cat ions ,  updates,  deletions,  insertions 
of  data  elenents,  procedures,  files  to  the  CDM 
Adninistrator . 

5.  Reconaend  nodi ficat ions ,  updates,  deletions,  insertions 
of  network  resources  or  services  to  the  IISS  Systen 
Adninistrator . 

6.  Design,  code,  nodify  new  or  existing  network  or 
hardware  specific  services. 

7.  Conpile.  link,  new  or  nodified  IISS  services  on 
specific  hardware. 

8.  Conpile.  link  new  or  nodified  IISS  network  services. 


9.  Test  new  or  nodified  hardware  specific  IISS  services  on 
existing  database  management  system,  without  down  time. 

10.  Test  new  or  modified  IISS  distributed  services  without 
Test  Bed  down  tine. 

11.  Install  tested  services  without  Test  Bed  down  time. 

12.  Create,  install  documentation  for  new  or  modified  IISS 
services  on  the  CDM.  Defer  effect ivity  until  CDM 
Administrator  review. 


13.  Measure  the  performance  of  new  or  modified  IISS 
services . 

14.  Read  only  access  to  the  IISS  error  log  file. 

15.  Trace  IISS  errors  to  offending  IISS  system  services. 
Correct  errors  if  necessary. 

16.  Upon  request  from  the  IISS  Administrator  remove 
existing  IISS  services  from  the  IISS  system  without 
Test  Bed  down  time. 
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B.6  CDM  Administrator  Scenarios 


B.6.1  CDM  Administrator  Definition 

A  person  within  the  CBIS  who  analyzes  information 
requirements  and  develops  the  neutral  data  structure. 

CBIS  2-1 

B.6. 1.1  Remark  on  the  Definition 

As  stated  above,  the  CDM  Administrator  definition  does  not 
emphasize  the  enforcement  role  of  the  CDM  Administrator  required 
to  implement  the  centralized  control  and  management  of  data 
contained  in  the  CBIS. 

Since  centralized  data  management  is  the  theme  of  CBIS.  the 
following  definition  of  the  CDM  Administrator  is  proposed: 

“A  person  within  the  CBIS  who  amalyzes  information 
requirements,  develops  the  neutral  data  structure,  enforces 
centralized  control  of  updates  to  the  neutral  data  structure, 
controls  access  to  the  meta  data  and  who  manages  the  CDM  support 
resources . " 

B.6. 2  CDM  Administrator  Role 

The  CDM  Administrator  main  mission  is  to  ensure  that  the 
data  contained  in  the  various  IISS  databases  is  described  in  the 
CDM  database,  that  this  description  is  stable  and  is  well 
control led . 

The  CDM  Administrator  has  the  additional  mission  of 
managing  the  CDM  resources  and  of  ensuring  continuous  operation 
of  the  CDM. 

B.6. 3  CDM  Administrator  Scenarios 


(see  Figure  B-5) 

B.6. 3.1  Develop  the  Meta  Data 


(see  Figure  B-6) 
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B.6.S.1.1  Definition  of  the  Meta  Data 

1.  Establish  Data  Requirements  for  each  IISS  subsystem. 

2.  Understand  and  model  the  IISS  data  resource. 

3.  Build  GODASTL  data  submodels . 

4.  Integrate  data  submodels  into  existing  IISS  data 
models. 

5.  Describe  a  data  record. 

Record  name 

Duplicate  authorization 
Access  authorization 
Attribute  description 
Procedure  description 

6.  Describe  a  set  type. 

Owner  record 
Member  record 
Set  membership  rules 
Insertion  (auto,  manual) 
retention  (fixed,  mandatory,  optional) 

Set  selection  rules 
key,  currency,  system 
Set  ordering  rules 

first,  last,  next,  prior,  nth,  default 
Duplicate  sets 

7.  Describe  an  IISS  application  process  from  data  supplied 
by  application  or  IISS  Service  Specifiers. 

8.  Understand  impact  of  an  IISS  application  process  on  the 
IISS  data  resources  from  the  following  new  points: 

•  Data  usage 

•  Data  origination/utilization 

•  Data  security 

e  System  throughput 

9.  Understand  IISS  user  data  needs. 

10.  Establish  IISS  user  security  privileges. 
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11.  Describe  OCL  con&ndB,  including  syntax,  help  file, 
aocess  privileges  fron  data  supplied  by  the  IX8S 
Service  Specifier. 

12.  Describe  the  neutral  DDL  and  DHL  oossands  including 
syntax,  help  file,  aooess  privileges  fron  data  supplied 
by  the  IISS  Servioe  Specifier. 

IS.  Describe  the  Ad-hoc  query  language  commands  including 
syntax,  help  file,  aocess  privileges  from  data  supplied 
by  the  IISS  Servioe  Specifier. 

14.  Describe  the  IISS  application  subsysteas  (address, 
protocols,  etc.) 

15.  Describe  the  various  IISS  database  aanagers  (error 
codes,  DDL  and  DHL  features,  navigation  operations. 

etc. ) 

16.  Describe  the  various  sequential  files  used  in  the  IISS 
systea. 

17.  Describe  the  terainal  characteristics  used  in  the  IISS 
6ystea  (address,  protocol,  etc.) 

18.  Establish  the  CDM  (or  CDMs)  logical,  physical  addresses 
and  access  rules. 

19.  Establish  the  CDM  error  file(s)  logical,  physical 
addresses  and  access  rules. 

20.  Describe  the  various  IISS  users  (priority,  access 
privileges,  identification). 

21.  Grant/Deny  IISS  user  data  access  privileges. 

22.  Grant /Deny  IISS  user  Beta  data  access  privileges. 

B. 6. 3. 1.2  Implement  the  Meta  Data 

1.  Insert  new  met a  data. 

2.  Update,  delete  existing  meta  data. 

3.  Access  existing  meta  data  by  record,  set  type, 
application  process,  etc. 
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Figure  B-5 .  AO  -  CDM  Administrator  Scenarios 
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Figure  B-8 .  A2  -  CDH  Data  Description 
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Figure  B-lO .  A4  -  CM!  Data  Description 
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Figure  B-ll.  A6  -  CDM  Data  Description 
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4.  Control  meta  data  revision  effeotivity. 

B.6.S.1.S  Test  the  Meta  Data 

1 .  Create  temporary  meta  data  for  test  purposes . 

2.  Test  for  record  type  name  uniqueness. 

5.  Test  for  set  type  name  uniqueness. 

4.  Check  syntax  of  data  model  against  CODASYL  syntax. 

5.  Check  ranges  and  units  of  data  items. 

B.6.3.2  Control  Access  to  the  Meta  Data 

B. 6. 3. 2.1  CDM  Version  Control 

1.  Establish  scope,  revision  number  of  CDM  data. 

2.  Create  temporary  revision  to  the  CDM  data,  and  control 
effectivity . 

3.  Automatically  update  CDM  revision  number  when  updates 
are  made  to  the  CDM. 

B.6.3.2. 2  Grant/Deny  CDM  Access  Privileges 

1.  Grant/Deny  CDM  access  privileges  to  specific 
individuals  or  groups  of  individuals. 

2.  Grant/Deny  CDM  aocess  privileges  to  specific 
application  processes  or  groups  of  application 
processes . 

B.6.3.2. 3  Enforce  CDM  Security 

1.  Maintain  a  CDM  access  audit  trail. 

2.  Screen  audit  trail  for  unauthorized  entries. 

B.6.3.3  Manage  CDM  Resources 

B. 6. 3. 3.1  Measure  CDM  Performance 

1.  Keep  running  log  of  CDM  accesses  by  user  types. 
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2.  Measure  mean  CDM  servioe  time  by  user  type6, 
application  process  type. 

B.6.S.S.2  Analyse  CDM  Error  File 

1.  Keep  running  log  of  CDM  errors. 

2.  Analyze  CDM  errors. 

S.  Resolve  CDM  errors. 

4.  Reset  CDM  error  file. 

B.6.3.3.3  Opt ini se  CDM  Database  Management 

1.  Optinize  single  CDM  database  manager 

2.  Duplicate  CDM 
B.6.3.4  Operate  CDM 

1 .  Back  up  the  meta  data . 

2.  Recover  the  meta  data  after  a  crash. 

B.7  IISS  System  Administrator  Role 

B.7.1  IISS  System  Administrator  Definition 

A  person  within  a  CBIS  who  operate  the  CBIS  Computer 
System. 

(CBIS  2-3) 


B.7. 1.1  Remark  on  the  Definition 


The  above  definition  defines  the  role  of  the  IISS  operator 
rather  than  the  role  of  IISS  system  administrator . 


The  following  definition  is  proposed:  "A  person  within 
IISS  who  administrates  and  manages  the  resources  allocated  to 
IISS.  In  particular  he  controls  the  level  of  manpower  and 
hardware  resources  required  by  IISS”. 


B.7. 2  IISS  System  Administrator  Role 

The  main  objective  of  the  System  Administrator  is  to 
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provide  a  system  view  to  the  administration  of  the  IISS 
resources . 

The  scope  of  IISS  System  Administrator  includes: 
e  Hardware  resources 

e  Manpower  resources  (IISS  Service  Specification  8 
Application  Specifier) 

e  CDM  administration  supervision 

e  IISS  operators 

Figure  B-12  is  an  organisation  diagram  for  IISS.  One 
individual  may  fulfill  one  or  several  roles. 

B.7.3  System  Administrator  Scenarios 

B.7.3.1  Administrator  IISS  Personnel 

1.  Direct  implementation  of  IISS  services  and  applications 

2.  Direct  and  control  IISS  service  specifier 

3.  Direct  and  control  IISS  application  specifier 

4.  Direct  and  control  the  CDM-Administrator 

5.  Direct  and  control  the  IISS  operator 

6.  Enforce  implementation  of  IISS  standards 

7.  Support  objectives  of  the  ICAM  Program  Office 

8.  Ensure  continuous  operations 

9.  Recommend  changes  to  IISS  standard  to  standard 
specifier 

B.7.3. 2  Administrate  IISS  Hardware  Resource 

1.  Audit  IISS  system  usage 

2.  Grant /Deny  IISS  user  access 

3.  Audit  IISS  user  response  time 
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4.  Audit  I1SS  hardware  performance  (LAN ,  HOSTS,  DBMS) 

5.  Recoaaend  addi ti on/del et ion  to  IISS  hardware  (LAN, 
Terminal ,  host) 

6.  Recoaaend  duplication  of  CDM  to  iaprove  performance 

7.  Enforce  IISS  security 

B.7.3.3  Per fora  Extraordinary  Recovery  Procedures 

1.  Unlock  database  accidentally  locked  by  user 

2.  Boot/restart  local  area  network 
B . 8  IISS  Standard  Specifier 

B.8.1  IISS  Standard  Specifier  Role  Definition 

A  person  who  foraulates  and  recoaaends  standards  which  aust 
be  satisfied  by  IISS  service  software  and  by  IISS  application 
software . 

B.8.2  IISS  Standard  Specifier  Mission  Definition 

The  main  objectives  of  the  IISS  Standard  Specifier  mission 
are  to  formulate  and  recommend  standards  which  promote  the 
usefulness  of  IISS  to  the  users  while  reducing  overall 
implementation  cost. 


The  IISS  Standard  Specifier  ensure  that  the  IISS  standards 
evolve  as  the  state-of-the-art,  state  of  application  in 
heterogeneous  distributed  processing  evolves. 


B.8.3  IISS  Standard  Specifier  Scenarios 


1.  Keep  current  with  state-of-the-art  of  IISS  support 
technologies . 


2.  Keep  current  with  latest  Federal,  commercial,  military, 
industry  standards . 

3.  Recommend  standards  to  be  applied  to  IISS. 


4.  Review  request  for  update,  modification,  deletion  of 
existing  standards. 


SRD620 140000 
1  Hovember  1985 


5.  Propose  update,  modif ioation,  deletion  of  existing 
standards . 

6.  Assist  CDM  Administrator  in  bringing  the  standards 
on-line. 

7.  Assist  IISS  service  specifier  and  application  specifier 
in  implementing  standards  recommendation. 

8.  Perform  audit  of  IISS  software  for  standard  compliance 
at  the  request  of  the  IISS  System  Administrator. 

B.9  I CAM  Program  Office 

B.9.1  ICAM  Program  Office  Role 

The  ICAM  Program  Office  guides  the  development  of  the  Test 
Bed  to  support  the  objectives  of  the  ICAM  Program  and  to  be  of 
maximum  value  to  the  ISMC  contractor. 


B.9. 2  ICAM  Program  Office  Scenarios 

B.9. 2.1  Definition  of  Integration  (inserted  here  at  the  request 
of  the  Air  Force) 


B.9. 2.1 
B.9. 2. 2 
1 . 


2. 


3. 

4. 

5. 

6. 
7. 


1  "Data  Integration" 

Scenarios 

Systematic  development  of  integration  technologies. 

Provide  visibility  into  cost  and  problems  of 
integration. 

Demonstrate  flexibility  of  the  integration  environment. 

Demonstrate  advanced  concepts  in  information 
management . 

Demonstrate  that  integration  is  workable  in  an 
evolutionary  mode. 

Support  the  2201  8  2202  development  and  integration. 
Simplify  the  task  of  the  2201  contractor. 
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8.  Validate  subsystems  before  implementation  on  X8MC. 

0.  Identify,  quantify  initial  performance  improvements. 

10.  Provide  proof  of  tangible  benefits  by  early  1088. 

11.  Run  I CAM  system  on  Test  Bed  before  implementation 

12.  Provide  seoond  verification  and  validation  to  I CAM 
software . 

18.  Educate  the  I CAM  community  to  the  total  XCAM  picture. 
B. 10  2201  Contractor  and  I CAM  Community 

B. 10. 1  2201  Contractor 

Aerospace  company  selected  by  the  I CAM  Program  Office  to 
implement  the  ISMC.  The  I8MC  relies  heavily  on  the  Information 
ManageiMnt  thread  implemented  by  the  Test  Bed. 

B. 10.2  2201  Contractor  Role 

The  2201  contractor  is  taking  advantage  of  the  Integration 
technologies  developed  in  the  Test  Bed  project  to  support  the 
implementation  of  the  I8MC. 

B. 10.3  2201  Contractor  Scenarios 

B. 11  Test  Bed  Demonstrators 

B.ll.l  Test  Bed  Demonstrator  Definition 

Persons  who  will  demonstrate  the  features  and  capabilities 
of  the  Test  Bed  to  the  I CAM  community,  the  I CAM  Program  Office 
and  the  2201  contractor . 

B.11.2  Demonstration  of  Basic  Technologies 

The  demonstration  environment  includes: 

e  Heterogeneous  oomputer  hardware 

--  IBM  4341,  VAX  11/780.  Honeywell  L-6 
(Later  IBM  30XX) 

e  Heterogeneous  database  management  system 

--  IDS- 1 1  .  IDHS.  VAX- 11  DBMS  (Later  INS.  TOTAL,  ff 
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ORACLE) 

•  Local  area  network 

1 .  Deaonstrate  simple  test  programs  acquiring  data  from 
one  or  many  databases. 

2.  Deaonstrate  staple  test  programs  updating  data  on 
one  or  aany  databases. 

5.  Deaonstrate  test  prograa  execution  control  via  IISS 

aes sages . 

4.  Demonstrate  canoe 1 /abort  function  with  roll  back  to 
clean  points. 

5.  Deaonstrate  generalised  interfacing  capabilities. 

6.  Deaonstrate  user  aooess  control  via  the  CDM. 

7.  Deaonstrate  data  oheok  control  via  the  CDM. 

8.  Demonstrate  data  modeling  checks  via  the  CDM. 

9.  Deaonstrate  LA>  data  transfer. 

10.  Demonstrate  virtual  terminal  capabilities. 

11.  Deaonstrate  preplanned  application  processes. 

12.  Deaonstrate  user  coaaand  language  commands 

13.  Deaonstrate  features  of  Interest  to  the  Program 
Office . 

14.  Deaonstrate  features  of  interest  to  the  2201 
contractor . 

15.  Deaonstrate  batch  processing. 

16.  Bench  Mark  Systea  against  known  stand  alone 
application. 

B.11.3  Deaonstrate  the  Integration  of  MRP.  HCMM.  IDSS 
1.  Iapleaent  selected  aanufacturing  scenarios 
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B.  12 

B.12. 
B.12. 
B.  12. 


B.12. 


B.12. 


2.  Demonstrate  preplanned  application  processes  requiring 
multi-base  queries. 

8.  Demonstrate  preplanned  application  processes  requiring 
multi-base  updates. 

4.  Conduct  the  demonstration  of  interest  to  the  I  CAM 
Program  Office. 

5.  Demonstrate  Test  Bed  features  of  interest  to  the  2201 
contractor . 

Test  Bed  Software 


1  Test  Bed  Software  Classification 

2  CDM  Scenar ios 


2.1  Meta  Data  Input  Functions 

1.  Provide  interactive  forms  to  enter/update/delete  meta 
data 

2.  Provide  controlled  access  to  enter/update/delete 
functions . 

3.  Provide  OODASYL  consistency  checks  to  meta  data 
definition. 

4.  Provide  access  to  meta  data  by  meta  data  item  name. 

5.  Provide  automatic  revision  number  to  meta  data. 

6.  Provide  temporary  update  of  meta  data  without 
effectivity  (test  mode). 

2.2  CDM  Maintenance 

1.  Provide  backup  facility. 

2.  Provide  physical  CDM  data  independence. 

3.  Provide  CDM  tuning  capabilities. 

2.3  CDM  Access  Control 

1.  Provide  meta  data  access  control  to  users. 
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2.  Maintain  neta  data  access  audit  trail. 

B. 12.2.4  CDM  Perfornanoe  Monitoring 

1.  Log  CDM  errors  in  error  file. 

2.  Provide  controlled  access  to  CDM  error  file. 

3.  Provide  selective  reset  capabilities  of  CDM  error  file. 

4.  Maintain  CDM  access  statistics  (service  tine  by  user) 

5.  Provide  controlled  aooess  to  CDM  access  statistics 
file. 

6.  Provide  selective  reset  capabilities  to  CDM  access  stat 
file. 

B.12.2.5  CDM  Processing 

1.  Translate  DBMS  specific  DML  call  into  neutral  DML 
format . 

2.  Translate  DML  call  in  neutral  format  to  target  DML 
format . 

3.  Translate  DBMS  specific  DDL  call  into  neutral  DDL 
format . 

4.  Translate  neutral  DDL  call  into  target  DDL  format. 

5.  Supply  message  verification  data  upon  request. 

6.  Supply  user  verification  data  upon  request. 

7.  Supply  data  conversion  data  (units)  upon  request. 

8.  Log  CDM  errors  in  CDM  error  file. 

9.  Down-load  selected  CDM  information  on  cold  start  to 
hosts . 

10.  Control  access  to  the  meta  data. 

11.  Provide  data  item  records,  set  types  description  upon 
request . 
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12.  Provide  CODASTL  oonsistenoy  oheoks  of  the  aeta  data. 

15.  Provide  synonyms  conversion. 

14.  Supply  data  itens  range  check  data  upon  request. 

15.  Provide  ad  hoc  query  language  syntax  checking. 

16.  Provide  error  oode  conversion  between  IISS  DBMs 
B. 12.5  IISS  Distributed  Services 

B. 12.5.1  Transaction  Processing 

1.  Provide  processing  of  predefined  systea  services. 

2.  Support  execution  of  predefined  procedures. 

5.  Support  cancel/abort  application  processes. 

4.  Support  subsystea  execution  control  aessage. 

5.  Support  batch  node  subsystea  execution  control. 

6.  Support  prioritised  application  processes. 

7.  Log  user  application  process  by  user,  application,  tiae 
staap. 

8.  Support  application  process  directory  by  user. 

0.  Support  selection  of  output  device  for  application 
prooess . 

10.  Create/delete/update  application  prooess  ooaaand  file. 

11.  Execute  an  application  process  coaaand  file. 

12.  Test  for  application  process  conpletion  status. 

15.  Support  begin  application  process  function. 

14.  Support  end  application  prooess  function. 

15.  8upport  aessage  definition  language. 
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16.  Invoke  other  application  processes. 

17.  Transaction  Definition  Lanuguage  (TDL)  to  be  6et 
oriented. 

18.  TDL  to  be  recursive. 

19.  TDL  to  contain  text  editor. 

20 .  TDL  to  be  non-procedural . 

21.  TDL  to  be  as  rich  as  PL/1. 

22.  Execute  an  application  process  in  test  node. 

B. 12.5.2  Ad  hoc  Query  Language 

1.  Provide  ad  hoc  query  language  to  query  the  various  IISS 
databases . 

2.  Provide  ad  hoc  query  language  to  query  sequential  IISS 
data  files. 

3.  Provide  ad  hoc  query  language  ooaaand  files. 

4.  Provide  ad  hoc  query  language  help  file. 

5.  Provide  access  control  to  the  ad  hoc  query  language. 

6.  Provide  ad  hoc  query  syntax  checking. 

7.  Provide  ad  hoc  query  language  functional  expension. 

8.  Invoke  ad  hoc  query  processing. 

9.  Exit  ad  hoc  query  processing 
B. 12.3.3  Connunicatlon  Services 

1.  Support  inforaation  transfer  between  two  subsystems. 

2.  Support  inforaation  transfer  between  subsystea  and  the 
CDM . 

3.  Support  transparent  inforaation  transfer  between  two 
users . 
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4.  Provide  guaranteed  delivery  of  data  update  requests. 

5.  Provide  logging  of  data  update  requests  for  each 
relevant  prooess. 

6.  Provide  logging  of  communication  errors. 

7.  Support  predefined  terminals  and  application  subsystem 
protocols. 

8.  Accept  and  provide  data  to  and  from  real  time  users. 

9.  Control  user  access  to  communication  services. 

10.  Synchronize  all  IISS  clocks. 

11.  Obtain  terminal  and  application  subsystem  protocols 
from  the  dm. 

12.  Transmit /receive  mail  between  two  IISS  users. 

13.  Download/upload  binary  data  and  programs. 

14.  Recover  a  down  node. 

B. 12.3.4  IISS  System  Servloes 

1.  IISS  log  in  function  with  user  access  control 
enforcement . 

2.  IISS  log  out  function. 

3.  IISS  bye  funotion. 

4.  IISS  application  aooounting  by  user. 

5.  IISS  help  funotion. 

6.  IISS  file  directory. 

7.  IISS  application  process  directory. 

8.  IISS  oanoel /abort  function. 

9.  IISS  system  and  application  status. 
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B.12.4  IISS  Hardware  and  DBMS  Specific  Functions 
B. 12.4.1  Virtual  Terminal 


1.  Support  predefined  terainal  protocols. 

2.  Support  predefined  application  subsystem  protocols. 

3.  Support  binary  down load /up load. 

B. 12.4.2  Application  Subsystea  Execution 

1.  Support  application  subsystea  execution  via  local 
message  processor. 

2.  Support  application  subsystea  cancel/abort  via  local 
aessage  processor . 


3.  Support  application  subsystea  status  query  via  aessage 
processor. 

4.  Send  aessage  to  another  IISS  application  subsystea  (on 
the  saae  host). 


5.  Send  aessage  to  another  IISS  application  subsystea  (on 
another  host). 


B. 12.4.3  Data  Update  Services  (Interfaced  or  Integrated) 

1.  Update  data  contained  in  a  local  DBMS. 

2.  Update  data  contained  in  a  local  sequential  file. 

3.  Update  data  contained  in  one  or  aany  reaote  DBMS. 

4.  Update  data  contained  in  one  or  many  remote  ISAM  files. 

5.  Perform  range  checks  on  data  to  be  updated. 

6.  Obtain  range  check  data  from  the  CDM . 

7.  Return  range  check  errors  to  application  program 
requesting  update.  Do  not  update  database. 


B. 12.4.4  Data  Query  Services  (Interfaced  or  Integrated 
1.  Query  data  contained  in  a  local  DBMS. 
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2.  Query  data  contained  in  a  local  sequential  file  via  an 
application  process. 

S.  Query  data  contained  in  one  or  many  renote  DBMS  via  an 
application  process. 

4.  Query  data  contained  in  one  or  many  sequential  files 
via  an  application  process. 

5.  Check  status  of  a  local  update  application  process 
(DBMS)  via  a  message . 

6.  Check  status  of  a  renote  update  application  process 
(DBMS)  via  a  ness age. 

7.  Check  status  of  a  local  update  application  process 
(Sequential)  via  a  nessage. 

8.  Check  status  of  a  renote  update  application  process 
(Sequential)  via  a  nessage. 

9.  Perforn  range  checks  on  data  which  is  retreived. 

10.  Obtain  range  check  data  fron  the  CDM . 

B.12.5  Application  Subsystem 
B. 12.5.1  Integrated  Application 

1.  Execute  an  Integrated  Application  which  queries  data 
contained  in  either  one  of: 

-  Local  DBMS 

-  Local  sequential  file 

-  One  or  many  DBMS,  local  or  renote 

One  or  nany  sequential  files,  local  or  remote 

2.  Execute  an  Integrated  Application  which  updates  data 
contained  in  either  one  of: 

-  Local  DBMS 

Local  sequential  file 
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-  One  or  n&ny  DBMS,  local  or  remote 

-  One  or  many  sequential  files,  local  or  remote 

3.  Execute  an  Integrated  Application  in  batch  mode. 

4.  Cancel  a  running  application  subsystem,  going  back  to 
clean  point. 

5.  Execute  an  Integrated  Application  which  contains  the 
following  COBOL  DHL  calls  or  equivalent: 

a.  Commit 

b .  Connect 

c .  Di sconnect 

d .  Erase 

e .  Fetch 

f.  Find 

g .  Free 

h.  Get 

i .  Keep 

j.  Modify 

k .  Order 

l .  Ready 

m.  Reconnect 

n.  Rollback 

o.  Store 

6.  Obtain  meta  data  from  CDM. 

7.  Perform  user  access  control. 
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8.  Obtain  status  of  previously  requested  query  or  update 
action. 

9.  Obtain  IISS  system  status. 

10.  Execute  an  application  process  oommand  file  with  framed 
commands . 

11.  Perform  checks  on  data  obtained  from  the  IISS  database. 

12.  Obtain  check  data  from  CDM. 

13.  Execute  an  application  subsystem  in  test  mode  (w/o 
update  on  DBMS ) . 

B. 12.5.2  Interfaced  Application 

1.  Obtain  data  via  interface  mechanism  from  either  one  of: 

a .  Human  user 

b.  Machine  user 

c.  Other  software  user 

2.  Obtain  interfacing  meta  data  from  the  CDM. 

3.  Supply  data  via  interface  mechanism  to  either  one  of: 

a .  Human  user 

b.  Machine  user 

c.  Other  software  user 

4.  Report  interfacing  errors  to  the  initiating  program. 

5.  Perform  checks  on  data  acquired  through  interface. 

6.  Execute  interfaced  application  in  test  mode  (w/o\update 
to  DBMS). 
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APPENDIX  C 

TEST  BED  MIGRATIOK  PATH 
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C . 2  Foreword 


This  document  maps  out  a  migration  path  for  the  I CAM  Test 
Bed  into  the  foreseeable  future.  The  time  horison  oonsiderd  in 
this  study  has  been  extended  to  1990.  It  is  felt  that  this  end 
point  is  reasonable  when  considering  the  accelerating  rate  of 
ohange  of  the  Computer  Industry.  8even  years  [document  written 
in  198S]  will  undoubtedly  bring  tremendous  changes  in  the 
economics  of  hardware  and  software,  which  would  make  longer  term 
predictions  unreliable. 

This  document  thus  sets  out  to  investigate  the  likely  role, 
configuration  and  features  of  the  I CAM  Test  Bed  oirca  1990.  To 
that  effect,  the  following  questions  are  considered: 

1.  What  will  be  the  role  of  the  Test  Bed  in  the  O.S. 
Aerospace  environment? 

2.  What  will  be  the  implementation  of  the  Test  Bed  in  such 
an  environment? 

S.  How  will  applications  be  implemented  on  the  Test  Bed  in 
the  same  environment? 

Taking  a  system  view  of  the  Test  Bed  requires  considering 
the  architecture  of  the  computer  system  (hardware  and  software) 
implementing  the  Test  Bed,  the  methodology  and  tools  required  to 
implement  additional  application  on  the  Test  Bed,  and  lastly, 
the  data  environment  of  the  Test  Bed.  These  three  faoets  of  the 
integration  of  manufacturing  data  on  the  Test  Bed  are  portrayed 
in  Figure  C-l. 

The  terms  shown  on  Figure  C-l.  Control  Architecture, 
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Plfvrt  C-l.  Kavironaent  of  the  Test  Bed 
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Computer  System  Architecture  and  Inforaation  Architecture  are 
defined  in  the  glossary. 

Figure  C-l  serves  as  a  configuration  dlagraa  for  this 
report.  The  inforaation  architecture  whioh  is  the  env Iron non t 
of  the  Test  Bed,  is  described  in  sufficient  detail  to  understand 
the  requireaents  placed  on  the  1090  Test  Bed.  This  description 
i6  contained  in  the  section  entitled,  “Test  Bed  Manufacturing 
Environment” .  It  nust  be  observed,  however,  that  the 
manufacturing  environment  of  the  Test  Bed  is  outside  the  soope 
of  the  Test  Bed.  It  is  the  forcing  funotion  of  the  Test  Bed, 
rather  than  a  foroe  controlled  by  the  Test  Bed  itself.  The 
Control  Architecture  and  the  Computer  Arohiteoture  are  on  the 
other  hand  directly  affeoted  by  the  design  strategy  and  by  the 
degree  of  implementation  of  the  Test  Bed.  Consequently,  this 
report  focuses  on  these  two  fundamental  aspects  of  the  Test  Bed. 

For  the  sake  of  saving  both  time  and  breath,  the  oomputer 
systea  described  here  which  supports  distributed  processing, 
distributed  intelligence  and  which  integrates  new  or  existing 
manufacturing  databases  is  referred  to  as  the  Test  Bed.  The 
rules  and  procedures  used  to  impleaent  additional  applications 
and  their  databases  on  the  Test  Bed  are  referred  to  as  the 
Integration  Methodology. 

C.3  Glossary 

CBIS  -  Computer  Based  Inforaation  Systea  -  A  CBIS  is  a 
"technology  environment"  defined  as  a  set  of  three 
architectures,  which  are  intended  for  the  management  of 
inforaation  within  a  factory  environment.  The  three 
architectures  include  an  Information  architecture,  a  computer 
system  architecture,  and  a  control  architecture.  The  CBIS 
interfaces  with  the  "real-time”  environment,  but  it  does  not 
contain  real-time  processor,  such  as  robots  and  numerically 
controlled  machine  tools. 

Computer  System  Archi tecture  -  the  aspect  of  a  FOF  that 
Includes  all  of  the  computer  hardware,  firmware,  operating 
systems,  communication  facilities,  data  management  facilities, 
programming  languages,  and  system  software  necessary  to  support 
the  physical  CBIS. 

Control  Architecture  -  the  aspect  of  a  CBIS  that  includes 
the  plans,  organizational  structure,  standards,  software 
engineering  methods,  procedures,  logical  data  models, 
cost-traoking  mechanisms,  etc.,  neoessary  for  integration  of  the 
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wall  r— iwfc>i  •UUatioa,  It  wl  pads  tills  pradioilot  to  the 
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Tho  above  illustrates  tho  key  contribution  of  the  Test  Bod 
to  tho  U.S.  Aerospace  Industry  aad  by  oonsequenoe  to  the  U.S. 
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Air  Foroe.  Slating  dearly  the  objective  is  a  necessary  but  not 
sufficient  condition  for  suooess.  A  ooaputer  systen  can  only  be 
successful  if  the  hardware,  software  architectures  and 
implementation  policies  are  oonaensurate  to  the  task.  The 
following  sections  of  this  report  set  the  stage  for  the  likely 
changes  in  the  hardware  and  software  oost  drivers  over  the 
forecast  period  (1900)  and  propose  a  migration  path  for  the 
hardware,  software  and  for  the  Test  Bed  Control  Architecture. 

C.6  Test  Bed  Computer  System  Architecture 

C.6.1  Test  Bed  Hardware  Environment 

The  hardware  environment  of  the  Test  Bed  of  the  1990 
reflects  the  following  considerations: 

1.  Increasingly  large  number  of  end-users 

One  major  study  indicates  that  by  1985,  70%  of  the  U.S. 
working  foroe  would  work  with  computers  for  at  least 
some  portion  of  their  work  activity. 

2.  Microprocessor  Eoonomios 

The  availability  of  small  personal  computers  is  evident 
in  all  walks  of  life.  The  microprocessors  have 
proliferated  because  of  their  low  cost,  and  the 
resulting  low  cost  per  machine  instruction  they  afford 
make  then  ideally  suited  for  application  programs  which 
require  only  8  or  16  bit  arithmetic. 

3.  Information  Storage  Economics 

The  rapid  advances  of  VLSI  technology  will  change  the 
storage  economics  as  megabit  storage  chips  become 
available.  Four  megabit  bubble  ohips  have  already  been 
developed  by  Intel  (1982).  Moore's  Law,  which  links 
the  number  of  storage  cells  per  cirouit  to  time,  has 
consistently  predicted  a  doubling  of  storage  capacity 
every  year  since  1964.  In  spite  of  these  rapid 
advanoes,  Moore's  Lav  predicts  some  future  for  the 
rotating  mass  memories. 

4.  Software  Path  Length 

The  operating  systems  of  large  general  purpose 
computers  are  increasingly  complex  and  add  a  very 
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significant  overhead  to  any  application  progran. 

The  nunber  of  operating  systea  instructions  executed  in 
support  of  an  application  prograa  is  referred  to  as  the 
software  path  length.  Studies  have  shown  that  on  large 
aain  f rases .  the  path  length  often  exceeds  100,000 
instructions,  whereas  on  saaller  aaohines  (aini's)  the 
software  path  length  is  often  less  than  2,000 
instructions . 

i 

6.  Advances  in  Teleprocessing 

Local  Area  Networks  have  brought  about  a  quant ua  Juap 
in  simplicity,  capacity  and  reduced  cost  with  whioh 
computers  can  be  interconnected.  The  current  intense 
standardisation  activities  in  this  area  will  further 
ease  the  interconnect ion  of  heterogeneous  oonputers  via 
off  the  shelf  DMA  interfaces  to  the  LAM.  The 
involveaent  of  ooapanies  such  as  IBM,  Texas 
Instruaents ,  DEC,  Intel  and  Xerox  guarantees  that 
widely  aooepted  LAM  standards  will  coexist  and  that 
gateways  between  standards  will  be  available.  Vide 
Area  Teleprocessing  with  increased  capacity  and  reduoed 
cost  is  also  a  certainty. 

C.6.2  Test  Bed  Hardware  Architecture 

The  hardware  architecture  shown  on  Figure  C-2  represents 
the  architecture  of  a  production  Test  Bed  suitable  for 
processing  in  the  Aerospaoe  Manufacturing  Bnvlronnent .  This 
architecture  offers  the  following  key  features: 

1 .  Local  Area  Network 

A  high  perfornance,  connerclally  available.  Local  Area 
Network  Is  used  to  interconnect  the  various  oonputer 
6ystens  shown  on  Figure  C-2.  The  Looal  Area  Network  is 
characterised  by: 

•  High  data  rates  (in  exoess  of  10  negabits) 

•  Network  configuration  capabilities 

•  Network  resouroe  nanagenent  capabilities  (errors, 
data  rates) 


•  Connercial  availability  of  gateways  to  other  LAN 
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—  VLSI  LAB  iatorf— oa  Booo—  available  Sa—  prod— is 
La vo  air— Sy  Bo—  aaaoaa eoS.  (D.  ELLIOTT)  TBo  sa— 
VLSI  latorfao—  will  also  all—  tBo  Sir— t  o— aootioo 
of  — rBs tat loos  to  tBo  LAB. 

Rapid  advaa— a  ia  fi—r optics  i stores—  soil—  aad 
iatorfaoo  tooBaology  ooa plod  to  tBo  favoraBlo  pr too 
trood  ia  t  —  fi  Bor  op  ties  itsolf  all—  tBo  foroo—  t  of  a 
sBift  to  fiBoroptioe.  a— y  fr—  o— vial  oaBlos . 
PiBoroptios  Bavo  aigaifio— t  advaa tagos  ovor  coaxial 
cables :  isolatioa.  BigB  throagBpat .  oa— 11— t 

ol— troaaf—  tie  iaa— tty.  aad  aro  labor— tly  diffioali 
to  tap  (tBoroby  Isoroaa lag  tbo  so—  rity  of  tbo 
network )  TBe  Boy  to  —pi  tali  stag  —  iBo  VLSI  LAS 
iatorfaoo a  is  iBo  asl— ti—  of  a  widely  aooopted  LAS 
standard  aad  iBo  sol— ti—  of  ‘popalar*  computers  aad 
work  stati— s. 

S.  Mini -Computer 

TBe  Bardwars  architecture  of  Figure  C-2  oan 
iatoroonnoot  a  largo  number  of  aini -computers  aad  other 
processors.  TBe  aim -ooaputers  need  not  be  — tirsly 
dedicated  to  the  Test  Bod.  They  are  used  to  support 
tBe  aanuf actur lng  application  programs  a—  in  exist— os 
aad  their  databases.  These  aini -ooaputers  will  also 
support  the  Test  Bed  ssrvioes  (BTM.  OOMM)  required  for 
the  integration  of  these  databases.  In  the  long  run, 
however,  n—  application  prograa s  are  aost  likely  to 
reside  on  the  work  stations.  Such  an  architecture 
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took  ooi  processors  enjoy  ito  following  advaaUfta  over 
fsosrsl  purpose  oeopeters:  I)  slap  lor  sod  ooro 
per f oral af  software  (skorior  software  ptU  length).  a) 
favorable  oosi  rails  (I  to  a)  la  iota,  aad  a)  greater 
sneer tty;  The  atooooo  of  general  purpose  profrans  oa 
ito  took  end  proooosor  aakoa  li  oaaior  io  audit  ito 
4aia  usage  unde  la  ito  eye  ten.  Ttoro  aro  ao  applioaiioa 
profraos  oooeailaf  oa  ito  ded looted  took  ood  prooossor. 
thereby  ollolaailaf  ito  ikroai  of  aalevoleat  profraos 
anal taring  daiatoso  activity  (VSXTS) .  As  of  this 
writing.  ito  spood  odvaaiafo  ol stood  toy  book  ood 
daiatoso  osoafaoiarors  toas  fat  lad  io  oaiorlal iso .  This 
spood  odvaaiafo  Is  aaltkoly  io  oaiorlal Iso  as  loaf  as 
the  took  ood  prooossor  asos  tko  saoo  aass  siorafo 
tootoolofy  as  Its  foaoral  parposo  ooasla. 

Mossafo  toadlor  Processors 

Tko  Tost  tod  rolios  hoavily  oa  iko  prooosslaf  of 
aoosafos  for  Its  ooordi station  aad  ooairol .  Dodloatod 
aossafo  haadlor  prooossors  aro  shown  on  Flfuro  C-2  to 
oarry  oal  tho  tins  ooasaaiaf  aossafo  handling 
operations  required  for  tho  rollatolo  prooosslaf  of  Tost 
tod  aossafo s  This  approach  further  off  loads  tho  book 
and  prooossors  (aad  oould  also  bo  applied  to  tho 
alnl-ooapaters  of  tho  Tost  tod)  aad  speeds  up 
processing.  This  approach  has  already  boon  used 
suooessfully  by  tho  Bank  of  Aaerioa  in  its  on-line 
banking  systoa  in  California  (VKXTZ).  Tho  aossafo 
handling  prooossors  could  iapleaent  part  of  tho  MTM 
functionality. 
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As  the  Test  Bad  moves  into  production,  tho  daaud  for 
om  hundred  poroont  availability  will  arise.  This  is 
because  tho  Tost  Bod  will  beoome  offoctivoly  tho  oyos. 
oars  and  brains  of  tho  manufacturing  environment . 
Redundant  hardware  provides  a  moans  for  reaohing  (with 
a  high  probability  of  suooess)  tho  100%  availability 
goal  since  single  failures  do  not  bring  the  system  to  a 
halt.  Redundant  hardware  also  facilitates  the 
scheduling  of  the  maintenance  operations.  Figure  C-2 
shows  how  redundant  hardware  oan  be  oonneoted  in  a 
cross  over  arrangement .  An  interprooessor  link  -  high 
speed,  vendor  supported  -  is  used  to  switch  over  the 
back  end  processors  and  message  handlers.  Such 
equipment  is  commercially  available.  Hardware 
redundancy  should  be  used  on  the  shared  portion  of  the 
system  orltioal  to  Test  Bed  operations. 

CAD/CAM  Graphic  System 

As  produot  Information  beoomes  increasingly  more 
Intertwined  with  process  information  required  to  run 
the  factory,  graphlo  systems  will  be  brought  into  the 
Test  Bed.  Such  addition  will  greatly  facilitate 
prooess  planning  and  the  programming  of  robots.  Direct 
interfacing  of  the  turn  key.  commercial  graphic  systems 
will  be  possible.  Strong  market  foroes  and  the 
emergence  of  standard  high  performance  VLSI  LAB 
interfaces  make  this  development  unavoidable  by  the 
CAD/CAM  vendors . 

Workstation 

Single  or  multiple  user  work  stations  provide  computer 
power  to  the  user  in  a  oost  effective  fashion.  Work 
stations  are  characterised  by  short  software  paths, 
sufficient  computing  power  (16  bit  floating  point)  and 
memory  to  support  the  User  Interface  functions 
(screens,  application  processes,  etc.)  associated  with 
the  Test  Bed.  The  trends  in  RAM  storage  technologies 
allow  to  foreoast  the  availability  of  1  to  4  megabits 
of  solid  state  RAM  storage  for  the  work  stations. 
Beoause  of  their  computational  capabilities,  work 
stations  distribute  the  intelligence  of  the  Test  Bed 
and  support  near  real  time  machine  sensors. 

These  sensors  allow  the  monitoring  of  robots,  NC 
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aaohlnes  and  other  process  paraseiers.  Prograss  ran  on 
the  workstations  are  down  loaded  fron  the  rotating  mass 
sensor les  via  the  LAB.  The  distributed  Intel ligenoe  of 
the  workstations  will  increase  significant iy  the 
throughput  of  the  Test  Bed  by  relieving  to  a  saxisus 
extent  the  processors  perforning  the  data  access 
operations. 

0.  Dial  Dp  Capabilities 

The  Bus  Interface  Units,  are  part  of  the  hardware 
architecture  of  the  1000  Test  Bed.  These  units  allow 
for  the  tine  shared  and  dedicated  interfacing  of 
terminals  and  personal  computers.  Personal  computers 
can  thus  be  temporarily  connected  to  the  Test  Bed  via 
dial  up  modem.  In  this  mode,  a  personal  computer 
becomes  a  non -dedicated  work  station  of  the  Test  Bed. 

C.6.S  Test  Bed  Software  Environment 


The  Software  Environment  of  the  Test  Bed  of  the  1000 
refleots  the  following  considerations: 


People  and  Computer  Economics 


The  year  1070  marked  the  crossover  point  of  the 
oomputer  and  people  oost  trend  lines,  with  people  cost 
now  exoeeding  oomputer  oost  in  most  DP  installations. 


Increasing  Share  of  Purchased  Software 


The  application  baoklog  now  existing  in  most  dp 
installations  and  the  increasing  oost  of  a  debugged 
line  of  software  make  purchased  software  that  much  more 
desirable.  It  has  been  estimated  that  by  1083,  20%  of 
application  software  will  be  purchased,  up  fron  0%  in 
1080  [ADMARTIB] . 


Stern  Resistance  to  Changing  Existing  Applications 


The  high  oost  of  a  debugged  line  of  code  (S10  per  line 
of  COBOL  on  the  average,  1080)  and  the  existing 
development  backlog  deter  DP  installations  fron  making 
changes  to  running  application  programs. 


Push  for  Data  Processing  Productivity 


I 
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The  data  processing  departments  are  under  increasing 
pressures  to  improve  the  productivity  of  their 
programing  staffs.  In  general,  this  push  results  in  a 
strong  preference  for  program  acquisition  in  lieu  of 
program  development .  Program  acquisition  has  several 
aspects:  it  can  be  accomplished  via  non -pr ooedur a 1 

languages,  very  high  level  languages,  shared  code 
(system  services)  and  database  management  systems. 

5.  Fewer  Professional  Programmers 

End  users  are  becoming  more  and  more  knowledgeable  in 
computer  scienoe  and  are  increasingly  desirous  and 
capable  of  developing  application  programs  quickly 
without  the  tedious  and  laborious  interfacing  with  the 
professional  programming  6taffs,  well  versed  in 
computer  soienoe  but  ignorant  of  applications. 

6 .  Database  Management 

Great  productivity  improvements  are  available  when 
application  programs  are  developed  for  use  with  a 
database  management  system.  Furthermore,  major 
application  programs  are,  for  this  economic  efficiency 
reason,  based  on  commercially  available  database 
management  systems. 

7.  Distributed  Data  Processing 

The  above  considerations  must  be  viewed  in  the  context 
of  Distributed  Processing.  Distributed  Data  Processing 
problem  is  a  ourrent  state  of  research  topic,  with  no 
full  fledged  commercial  solution  to  the  Distributed 
database  Management  problem. 

C.6.4  Test  Bed  Software  Architecture 

The  Software  Architecture  of  the  Test  Bed  of  the  1990 
reflects  the  ooncernsfor  people  productivity  and  for  the 
efficient  use  of  computer  resources.  In  particular,  the 
software  architecture  allows  the  distribution  of 
Intel 1 igenceamong  the  various  work  stations.  This  minimises  the 
load  placed  on  the  processors  having  the  burden  of  processing 
the  various  data  access  operations. 

1.  Predefined  and  Ad-Hoc  Capabilities 
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Predefined  and  ad-hoe  distributed  query  and  update 
capabilities  ooexist  on  the  Test  Bed  for  efficiency 
reasons . 

2.  Layered  Software  Structure 

Figure  C-5  shows  the  layered  structure  of  the  Test  Bed 
Software.  Figure  C-5  illustrates  a  Test  Bed 
Integrating  three  different  databases  supported  by 
three  different  database  aaaagers.  Figure  C-S  depicts 
the  predefined  and  ad-hoc  capabilities. 

5.  Distributed  Software  Arohi teoture 

The  distribution  of  the  Test  Bed  Software  across  the 
aini-ooaputers,  the  workstations  and  the  back  end  data 
nachines  allows  significant  iaproveaents  in  processing 
perforaanoe.  The  functional  distribution  of  the 
software  nay  take  on  several  forns,  depending  on  the 
availability  of  the  hardware,  and  on  the  location  of 
existing  applications  in  the  network. 

a.  Initial  Distribution  of  the  Test  Bed  Software 

Figure  C-4  shows  the  initial  breakdown  of  the  Test 
Bed  Software  into  independent  functional  nodules. 
For  sinplicity.  the  Test  Bed  Servioes  are  not  shown 
on  Figure  C-4.  By  reference  to  this  figure,  it  can 
be  seen  that  sone  level  of  parallel  processing  can 
be  achieved.  However,  in  this  arrangement  the  User 
Interface  functions  and  the  application  program  are 
supported  by  the  processors  performing  the  data 
access  operations. 

b.  Future  Distribution  of  the  Test  Bed  Software 

Future  distribution  of  the  Test  Bed  Software. 

Figure  C-5,  shows  the  future  distribution  of  the 
Test  Bed  Software  into  independent  software 
nodules.  This  figure  assunes  that  a  workstation  of 
sufficient  computing  power  is  available.  In  the 
predefined  query/update  environment,  a  work  station 
of  nininun  sophistication  is  sufficient.  In  the 
ad-hoc  environment,  more  computing  power  and  memory 
are  required  to  support  the  parsing  and 
decomposition  of  the  user  requests  into  single  node 
transactions.  Figure  C-5  maximises  parallel 
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processing  and  frees  to  a  maximum  exteat  possible 
the  processors  performing  the  data  access 
operations. 

This  arrangement .  it  must  be  noted,  accommodates  a 
large  number  of  users  in  the  ad-hoc  environment, 
sinoe  the  overhead  related  to  the  ad-hoc 
processing  is  maximally  distributed. 

4.  Shared  Code  and  Servioes 

To  maximise  programmer  productivity  the  Test  Bed 
allows  the  sharing  of  existing  code.  This  applies 
to  system  servioes  such  as  user  soreen6  and  data 
integrity  oheoking  software.  Transaction 
processors  already  written  and  tested  are  shared 
among  users. 

5 .  Report  Generator 

A  report  generator  facilitates  the  accessibility  of 
the  data  by  the  user. 

6.  Higher  Level  Language 

A  Higher  Level  Language  allows  the  non-procedural 
definition  of  user  specified  processing.  This 
language  offers  oontrol  capabilities  and  defines 
macro  operations  of  special  interest  to  the 
manufacturing  end  user.  These  macro  operations 
represent  frequent  and  well  defined  operations  in 
the  manufacturing  environment.  Moving  tools  from 
the  tool  crib  to  the  manufacturing  oell  or  station 
represent  an  example  of  a  typical  macro  operator 
routinely  performed  by  the  Test  Bed  users. 

7.  Integration  of  Non-Codasyl  Databases 

The  Test  Bed  allows  the  integration  of  non-Codasyl 
databases.  Of  particular  interest  to  the  U.S. 
Aerospace  Environment  are  the  hierarchical  and 
indexed  sequential  database  structures.  Specific 
instances  of  these  database  structures  will 
progressively  be  Integrated  on  the  Test  Bed  by 
extending  to  these  DBMS  the  Neutral  Data 
]  Manipulation  Language  of  the  Te6t  Bed.  IMS,  and 

I  TOTAL  are  examples  of  the  DBMS  of  interest, 

i 
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8.  Intelligent  Retrieval  from  Databases 

Artificial  Intelligence  Techniques  are  beooning 
available  to  carry  out  intelligent  data  retrievals 
from  databases.  Of  particular  importance  to  the 
manufacturing  environment  is  the  fulfillment  of  a 
query  which  requires  knowledge  not  explicitly 
stored  in  the  database  but  whioh  is  common 
knowledge  among  the  users  of  the  system.  The 
representation  and  usage  of  the  required  oonmon 
knowledge  requires  Artificial  Intelligence 
Methodology.  [MILS]. 

9.  Natural  Language  Processing 

Although  relational  algebra  permits  the  exact 
definition  of  ad-hoc  query,  in  a  concise, 
non-procedural  format,  it  does  suffer  from  a  lack 
of  user-friendliness.  Natural  Language  processors 
provide  a  bridge  between  the  user  and  the  query 
processors  by  performing  the  semantic  analysis  of 
the  user  natural  query  and  its  transposition  into 
its  relational  algebra.  ON-LINE-ENGLISH  is  such  a 
natural  language  processor  whioh  is  commercially 
available.  The  use  of  a  natural  language  processor 
in  the  manufacturing  environment  is  very  desirable 
for  obvious  reasons  [CDATE] . 

10.  Performance  Optimisation 

The  initial  Test  Bed  implementation  provides  a 
first  level  of  performance  optimisation.  Given  a 
oonoeptual  data  retrieval  path,  the  first 
implementation  of  the  Test  Bed  minimises 
transmission  oost  based  on  the  actual  volume  and 
pathing  is  performed  without  optimisation.  Further 
performance  gains  can  be  realised  by  optimising  the 
conceptual  and  internal  paths  followed  to  retrieve 
the  data.  Such  optimisation  requires  the  use  of 
heuristics  graph  search  procedures  described  in  the 
Artificial  Intelligence  literature  [NILS].  The 
performance  optimisation  oan  be  used  for  both 
predefined  queries  and  for  ad-hoc  queries. 
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C.6.5  Test  Bed  Data  Environment 

The  data  environment  of  the  Test  Bed  of  the  1990  reflects 
the  following  considerations: 

1.  Existing  Databases 

The  databases  which  exist  in  a  given  manufacturing 
environment  must  be  preserved.  These  databases  contain 
information  of  vital  importance  to  the  entreprise  and 
are  tied  to  a  gigantio  software  investment  whioh  cannot 
be  economically  altered.  These  databases  are.  in 
general .  heterogeneous . 

2.  Data  Integrity 

The  integration  of  databases  plaoe6  a  premium  on  data 
integrity  since,  in  the  distributed  environment,  errors 
affeot  unsuspecting  users  and  sinoe  errors  may 
propagate  in  a  fashion  unknown  to  the  human  user. 

3 .  Data  Independence 

Although  reasonably  stable,  the  data  resource  must  be 
flexible  to  allow  addition  and  deletion  reflecting  new 
operating  conditions  or  level  of  integration.  Changes 
to  the  data  resources  must  not  be  allowed  to  impact  the 
investment  made  in  the  software  processing  the  data. 

4 .  Data  Redundancy 

Some  level  of  data  redundancy  must  be  allowed  to 
improve  system  performance  and  availability.  Data 
redundancy  is.  however,  a  thorny  issue  sinoe  it  impacts 
adversely  on  data  integrity  and  complicates 
signif icantly  the  update  logic.  In  the  Test  Bed.  some 
level  of  redundancy  is  inherited  from  existing 
databases  and  must  be  dealt  with. 

5.  Data  Relatability 

Addition  to  the  data  resource  must  be  related  to  the 
data  already  existing  in  the  data  resouroe.  The  new 
addition  blends  in  and  can  be  manipulated  by  the  same 
tools  and  to  the  same  extent  than  the  original  data. 
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6.  Data  Accessibility 

The  data  contained  in  the  databases  integrated  by  the 
Test  Bed  nust  be  easily  accessible  by  the  authorised 
users.  Data  aooessed  frequently  is  aooessed  via 
predefined  and  precompiled  transactions.  Data  aooessed 
less  frequently  is  aooessed  via  ad-hoc  queries. 
Precompiled  transactions  and  precompiled  queries  must 
coexist. 

7 .  Data  Shareabi 1 i ty 

The  data  contained  in  the  databases  integrated  by  the 
Test  Bed  must  be  shared  between  several  users.  The 
Test  Bed  must  provide  the  environment  where 
simultaneous  data  can  be  retrieved  and  updated  without 
interference  between  the  various  users. 

8.  Data  Security 

Adequate  level  of  data  security  must  be  provided  to  the 
Test  Bed  data.  Data  security  must  be  oommensurate  with 
the  threats  of  loss  of  confidentiality  since  the  more 
seoure  data  security  precautions  are  invariably  the 
more  costly  of  system  resources. 

9.  Data  Effect ivity 

Management  of  the  data  life  cycle  is  an  important 
aspect  consideration  for  manufacturing  data. 
Manufacturing  data  evolves  accordingly  to  a  well 
defined  life  oycle:  preliminary,  design,  fabrication, 
maintenance,  archive.  The  ability  to  treat  each  datum 
accordingly  to  its  position  in  the  data  life  cycle  is 
required  to  support  Aerospaoe  Manufacturing. 

10.  Data  Typing 

Well  defined  data  types  are  provided.  The  definition 
of  the  data  types  includes  the  definition  of  the 
domains  and  of  the  legitimate  operations  that  can  be 
applied  to  those  domains.  The  enforcement  of  the 
constraints  on  the  defined  data  types  are  provided  by 
shared  system  services. 
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C.7  Test  Bed  Control  Architect are 

The  oontrol  architecture  of  the  Test  Bed  provides  the 
■ethodology  end  the  tools  required  to  implement  nev  applications 
amt  databases  on  the  Test  Bed.  The  Methodology  and  tools 
provided  allow  for  the  addition  and  nodifioation  to  the  data 
structure  which  supports  the  Test  Bed.  In  short,  the  oontrol 
architecture  deals  with  the  oreatlon  and  maintenance  of  the  Test 
Bed  Common  Data  Model . 

For  the  Test  Bed  to  be  implementable  in  the  production 
environment,  the  integration  methodology  used  to  integrate 
databases  must  be  dearly  established  and  further  it  must  be 
automated . 

1.  Application  Development 

Guidelines  (in  the  form  of  programming  guides)  explain 
how  to  develop  an  application  prooess  which  utilises 
the  servioes  of  the  Test  Bed  (screens.  Integrity 
checks,  etc.)  and  which  performs  distributed  query  and 
updates  on  the  databases  integrated  by  the  Test  Bed. 

2.  Common  Data  Model  Version  Control 

Version  control  of  the  Common  Data  Model  is  provided. 
Changes  to  the  Common  Data  Model  are  automatically 
logged.  Affected  application  processes  and  system 
servioes  are  flagged  for  recompilation.  Application 
processes  and  system  servioes  obsoleted  by  changes  to 
the  Comnon  Data  Model  are  prevented  from  being  executed 
by  Test  Bed  servioes. 

3.  Computer  Assisted  IDEF1 

Computer  assisted  IDEF1  modelling  tool  allows  the 
generation  of  normalised  IDEF1  models  in  support  of  the 
Test  Bed  integration  methodology  and  activities.  This 
semi -automated  tool  allows  the  interactive  checking  and 
building  of  IDEF1  models.  The  tool  is  used  to  ensure: 

e  Uniqueness  of  key  classes  as  identifiers  of  entity 

classes 


e  Migration  of  inherited  key  classes 
e  Compliance  with  the  no  null  no  repeat  rule  for 
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attribute  olasses 

e  Detailing  of  relation  olasses  (cardinality,  tine 
dependence,  boolean,  eto.  constraints) 

e  Detailing  of  path  assertions 

e  Detailing  attribute  class  doaain  constraints 

The  tool  is  used  in  the  following  scenarios: 

e  Construction  of  an  isolated  IDEF1  aodel 

e  Construction  of  an  IDEF1  aodel  of  an  existing 

database  defined  by  its  external  schema  (which  will 
become  an  internal  schema  for  the  Test  Bed) 

e  Augmentation  of  the  IDEF1  model  to  the  conceptual 
schema  of  the  Test  Bed 

4.  Computer  Assisted  Mapping  Definition 

A  computer  assisted  tool  allows  the  definition  of  the 
External  to  Conceptual  and  Conceptual  to  Internal 
mappings  required  to  integrate  databases  and 
application  processes.  This  tool  aocepts  as  input  the 
External  and  Conceptual  schemas  already  defined  and 
prompts  the  CDM  Administrator  to  fully  define  the 
corresponding  mappings.  Likewise,  the  tool  accepts  the 
Conceptual  and  Internal  schemas  as  input  and  prompts 
the  CDM  Administrator  to  define  the  Conceptual  to 
Internal  mappings. 

5.  On  Line  Data  Dictionary 

An  on  line  data  dictionary  is  automatically  maintained 
from  the  External ,  Conceptual  and  Internal  schema 
definitions.  The  dictionary  is  used  by  the  CDM 
Administrator  to  keep  track  of  the  entity  classes, 
attribute  classes,  and  domain  constraints  already 
defined  to  the  Test  Bed.  Sufficient  information  is  kept 
about  entity  classes  and  attribute  classes  to 
unequivocally  identify  the  semantics  of  each  class. 

6.  Application  Process  Interference 

The  data  dictionary  records  the  possible  interference 
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between  the  Application  Processes.  Interference 
possibility  is  deduoted  fron  the  external  schemas 
associated  with  the  application  processes.  This 
approach  allows  oonourrent  processing  of 
non- interfering  application  processes  and  greatly 
enhance  systen  throughput  (SDD-1). 

7.  Test  Bed  Resource  Manageaent 

Resource  management  capabilities  are  provided  to 
support  the  assessment  of  Test  Bed  usage  patterns. 

This  information  is  required  for  the  tuning  of  the  Test 
Bed,  and  for  budgetary  oontrol . 

8.  Data  Distribution  Strategy 

Guidelines  assisting  in  distributing  the  data  optimally 
in  the  Test  Bed  are  provided.  These  guidelines  provide 
the  CDCDM  Administrator  with  sufficient  information  to 
decide  upon  the  degree  of  redundancy  desirable  for 
optimum  system  performance  as  well  as  the  distribution 
of  the  data  in  the  various  databases  integrated  by  the 
Test  Bed. 

9.  Augmentation  to  the  Conceptual  Schema 

A  methodology  supporting  the  development  and 
augmentation  of  the  conceptual  schema  is  provided.  The 
methodology  provides  an  IDEFO  of  the  procedures  to  be 
followed  and  an  IDEF1  model  of  the  information  to  be 
gathered . 

10.  External  Schema  Definition 

A  computer  assisted  tool  is  provided  to  assist  the  CDM 
Administrator  in  building  the  external  schemas  used  by 
the  various  application  programs.  This  tool  provides  a 
systematic  procedure  to  the  definition  of  the  external 
schemas  built  by  the  user.  The  items  contained  in  a 
typical  external  Bchema  are  described  on  Figure  C-6. 

11.  Internal  Schema  Definition 

A  oomputer  assisted  tool  is  provided  to  a6si6t  the  CDM 
Administrator  in  building  the  internal  sohema 
definitions  used  in  the  Test  Bed. 
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12.  Conceptual  Schema  Definition 

A  computer  assisted  tool  is  provided  to  assist  the  CDM 
Administrator  in  building  the  internal  schema 
definitions  used  in  the  Test  Bed.  The  items  needed  to 
be  defined  in  a  typical  conceptual  soheaa  are  shown  on 
Figure  C-7. 

C.8  Migration  Path 

C.8.1  Hardware  Migration  Path 

Figure  C-8  shows  a  likely  migration  path  for  the  Test  Bed 
hardware.  Figure  C-8  doe6  not  imply  a  time  scale,  but  portrays 
what  is  believed  to  be  the  most  likely  sequencing  of  hardware 
addition  to  the  Test  Bed. 

It  is  realised  that  the  ICAM  Program  Office  is  not  in  the 
computer  hardware  business.  This  hardware  progression  is  6hown 
to  focus  on  the  capabilities  of  the  Test  Bed  as  time  goes  on  and 
to  help  the  planning  of  the  software  activities  required  to 
support  the  evolution. 

The  items  referenced  in  this  section  have  been  previously 
described  (see  Hardware  Architecture).  Items  102  are 
currently  available. 

Items  3  8  4  -  The  LAN  configuration  unit  and  self  trouble 
shooting  capabilities  (Item  3)  and  the  Direct  LAN  interfaces 
(Item  4)  will  be  developed  by  the  LAN  vendors  and  will  not 
impact  significantly  the  ICAM  software. 

Item  5  -  The  workstations  and  their  direct  LAN  interfaces 
will  also  be  developed  by  Independent  hardware  vendors.  Some 
rehosting  of  Test  Bed  software  and  application  programs  is 
implied  to  take  advantage  of  the  work  station  concept. 

Item  6  -  The  Message  Handler  processors  will  improve  the 
throughput  of  the  Test  Bed.  The  processors  are  off  the  shelf 
computers  (small  mini,  large  micros)  and  are  readily  available. 
Software  rehosting  and  possible  extension 
(encrypt ion /decrypt ion)  is  implied. 

Item  7  -  The  Back  End  processors  are  available  (IDM,  etc) 
as  their  introduction  in  the  Test  Bed  will  imply  integration 
work  with  existing  Test  Bed  software.  The  current  NDML  planned 
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EXTERNAL  SCHEMA 


USER  ID  AND  TYPE  (HUMAN  OR  SOFTWARE  MODULE) 

EXTERNAL  SCHEMA  ID  AND  AUTHORIZED  USERS 
SURROGATE  ENTITY  CLASSES  V/I  EXTERNAL  SCHEMA 
DATA  ITEMS  W/I  SURROGATE 
DATA  ITEM  PAIRS  BETWEEN  SURROGATES 

SEC  RELATIONSHIPS  BETWEEN  SURROGATES  W/  LINK  TO  DATA 
ITEM  PAIRS 

DATA  ITEM  PAIRS 

ALGORITHMS  FOR  DERIVED  DATA  ITEMS,  CONSISTING  OF: 
e  MODULE  ID 

•  DATA  ITEMS  USED  AS  PARAMETERS 

•  SEC  RELATIONSHIPS  THAT  SERVE  AS  “PATHS”  FOR 
OBTAINING  VALUES 


Figure  C-6.  External  Schema 


CONCEPTUAL  SCHEMA 


ENTITY  CLASSES 

ATTRIBUTE  CLASSES  AND  DOMAINS 
ATTRIBUTE  USE  CLASSES  -  KEYS 

-  OWNED 

-  INHERITED 

RELATION  CLASSES  -  TYPE 

-  INDEPENDENT  ENTITY  CLASS 

-  DEPENDENT  ENTITY  CLASS 
ALGORITHMS  FOR  DERIVED  ATTRIBUTE  CLASS 


Figure  C-7 .  Conceptual  Schema 
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for  the  Test  Bed  will  facilitate  this  integration. 

I ten  8  -  The  CAD/CAM  systems  available  at  the  time  of  this 
writing  have  limited  or  nonexistent  networking  capabilities. 
This  development  is  unavoidable.  The  addition  of  CAD/CAM 
systems  in  the  Test  Bed  will  be  facilitated  by  the  IGES 
standardisation  work  now  in  progress  at  General  Eleotrio  and 
other  researoh  institutions.  Significant  software  development 
may  be  required  to  interface  the  graphic  databases  to  the  Test 
Bed.  Interfacing  difficulties  arise  from  the  current  lack  of 
standardisation  among  the  graphic  databases  of  various  vendors. 

Item  9  -  Hardware  Redundancy  is  available  from  several 
vendors  (General  Automation,  etc.).  Installation  of  redundant 
hardware  will  only  be  justified  when  the  Test  Bed  moves  into 
heavy  production  status. 

C.8.2  Communication  Software  Migration  Path 

Figure  C-9  shows  the  likely  migration  of  the  Test  Bed 
Communication  Software.  Figure  C-9  does  not  imply  a  time  scale. 

Item  1  -  Binary  File  Transfer:  Binary  file  Transfer 
capabilities  are  needed  on  the  Test  Bed  to  transfer  graphic 
data,  execute  code  between  hosts  and  work  stations,  etc.  The 
transfer  of  binary  files  will  become  practical  when  the  direct 
LAN  interfaces  are  provided. 

Item  2  -  Direct  LAN  Interfaces:  The  integration  of  Direct 
LAN  interfaces  into  the  Test  Bed  requires  some  modification  to 
the  OOHM  Software.  Direct  LAN  Interface  device  drivers  are  to 
be  Integrated  into  the  existing  COMM  Software. 

Item  3  -  Message  Handling  Processors:  Rehosting  some  of 
the  NTM  functionality  is  required  to  take  advantage  of  the 
Message  handling  Processors  described  in  Figure  C-9.  The 
rehosting  of  the  NTM  functionality  on  the  Message  handling 
processor  also  requires  software  interface  between  the  software 
resident  on  the  Message  Handling  Processors  and  the  software 
resident  on  Test  Bed  Hosts  and  back  end  data  machines. 

C.8.3  Distributed  Database  Management  Migration  Path 

Figure  C-10  shows  the  likely  migration  of  the  Test  Bed 
Distributed  Database  Management  Software.  Figure  C-10  does  not 
imply  a  time  scale. 


Figure  C-lO.  Distributed  Database  Management  Software 
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Itea  1  -  Serialisation  and  Confliot  Analysis  [DPMARTIB] : 
Interference  between  two  Application  processes  aust  be  avoided 
if  the  distributed  database  aanageaent  systea  is  to  yield 
consistent  results.  Interference  between  two  Application 
processes  aay  occur  when  both  Applications  atteapt'to  update  the 
saae  data  or  when  an  application  prooess  is  reading  data  being 
updated  by  an  other  Application  Prooess.  The  first  case  is  the 
well  doouaented  interference  problea  occur ing  in  distributed 
updates.  The  second  oase,  perhaps  less  obvious,  occurs  in  the 
Environaent  of  the  620IM  Test  Bed.  The  following  examples 
illustrate  these  two  types  of  oonflict. 

1.  Distributed  Update  Interference 

Two  application  prograas  A  and  B  update  the  saae  datua 
Xo.  The  following  aay  occur: 

a.  Bo  interference 

A:  Xo  Xo  +  Xa 

B:  Xo  +  Xa  Xo  +  Xa  +  Xb  (final  state) 

b.  Interferences 

A:  Xo  Xo  +  Xa 

B:  Xo  Xo  +  Xb 

The  final  state  of  the  database  will  depend  on  the 
actual  sequence  of  execution  of  the  two  updates,  and  is 
in  either  oase  inoorrect. 

2.  Distributed  Read  Interference 

Two  Application  Prograas  A  and  B  read  the  saae  datua 
Xo.  Application  Process  A  updates  the  datua,  whereas  B 
does  not.  The  following  aay  occur:  B  will  either 
read  Xo,  or  Xo  +  Xa.  The  value  read  by  B  depends  upon 
the  aotual  sequencing  of  A  and  B.  If  B  uses  the 
retrieved  value  to  update  an  other  database, 
consistency  aay  be  lost. 

These  two  exaaples  show  that  in  the  distributed 
environaent,  sequencing  of  the  processing  alters  the 
end  results.  The  following  iaportant  practical 
iaplioations  result  froa  the  above  exaaples: 

a.  Without  systea  iaposed  sequencing  (or 

serialisation)  consistency  aay  be  lost,  without 
user  warning 
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b.  Recovery  and  nornal  processing  are  not  necessarily 
equivalent 

c.  The  systen  is  not  repeatable 

In  a  centralised  systen,  database  looking  is  used  to  prevent  the 
above  aentioned  problens.  This  approach,  although  feasible, 
results  in  severe  degradation  in  systea  throughput  and 
perforaanoe  in  the  distributed  environaent  [SDD-1].  Instead, 
systeas  such  as  SDD-1  rely  on: 

a.  Tiae  staap  driven  processing 

b.  Application  prograas  are  characterised  by  the  data 
they  acoess.  This  characterisation  allows  the 
deterai nation  of  potential  conflict,  at  run  tiae, 
between  application  processes.  The  inforaation 
required  to  character i sed  the  application  processes 
is  deterained  at  ooapile  tine  or  through  analysis 
prior  to  execution  tiae. 

I tea  2  -  Restart  0  Recovery:  Restart  and  Reoovery 
capabilities  aust  be  provided  to  allow  the  restart  and 
correction  of  a  database  which  has  been  teaporarily  unavailable 
or  which  has  been  oontaainated  with  erroneous  data.  The 
following  scenarios  are  typioal  scenarios  requiring  a  recovery 
action  to  be  initiated: 

a.  Database  is  known  to  contain  erroneous  data. 

b.  Database  contains  inconsistent  data. 

c.  Database  has  been  updated  with  data  which  nay  be 
erroneous . 

d.  Database  has  crashed. 

Hardware  failures,  systen  software  and  Application  Process 
Software  failures,  operator  errors  are  typical  causes  for  the 
above  scenar i os . 

The  third  scenario  typioal ly  arises  fron  updates  derived 
froa  corrupted  data  contained  in  an  other  database.  This 
failure  aeohanisn  makes  the  reoovery  of  databases  in  a 
distributed  environaent  that  auch  aore  difficult  to  perfora, 
sinoe  the  propagation  of  an  error  is  systea  usage  dependent. 
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The  restart/and  recovery  procedures  implemented  on  the  the 
Test  Bed  rely  on  the  following  concepts: 

a.  The  states  of  the  databases  used  as  starting  points  in 
a  recovery  action  nust  be  valid  and  consistent. 

b.  Update  Transactions  are  applied  without  omission  or 
duplication. 

c.  Recovery  processsing  is  equivalent  to  normal 
processing,  so  that  the  final  states  reached  during 
normal  processing  and  during  recovery  processing  are 
identical . 

d.  Recovery  procedures  include  the  recovery  of  the 
databases  and  of  the  serialised  transactions  queues. 

e.  Recovery  procedures  are  initiated  Manually.  The 
operator  can  either  roll  back,  roll  forward,  or  reapply 
transaction  streams.  The  initial  and  final  states  used 
in  rolling  back,  rolling  forward  are  specified  by  the 
user.  Selected  Transactions  can  be  omitted  from  the 
input  streams.  This  capability  allows  to  repair 
databases  contaminated  by  erroneous  Application 
Processes  by  ignoring  the  Application  Processes  for  the 
time  being. 

Item  3  -  Ad-Hoc  Query  (Predicate):  Ad  Hoc  query 
capabilities  based  on  Relational  Calculus  enhance  the  power  of 
the  Test  Bed  System,  by  making  test  bed  information  more  readily 
accessible  to  the  user.  This  first  level  of  ad-hoc  query 
capabilities  is  not  as  user  friendly  as  may  be  desirable. 
Friendlier  query  capabilities  based  on  Natural  language 
processing  are  described  under  Item  9.  The  Capabilities 
described  here  are  viewed  as  the  building  blocks  to  the  Natural 
Language  Query  Capabilities. 

The  6201M  Test  Bed  provides  for  predefined  queries.  The 
design  of  the  6201M  query  processors  provide  the  building  blocks 
to  the  follow  on  ad-hoc  capabilities. 

The  software  required  to  input  the  query,  parse  the  query, 
generate  the  query  generators  and  distribute  the  COBOL  query 
processor  code  must  be  developed.  Of  importance,  is  the 
software  required  to  enforoe  authorised  acoess  to  the  data. 
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I tea  4  -  Distributed  Updates:  The  software  supporting 
distributed  updates  needs  to  be  developed.  Speeif ioally.  the 
distributed  updates  are  performed  in  CBXS  CLASS-1,  that  it  is 
the  updates  are  perforned  under  oontrol  of  the  COM.  This 
capability  brings  about  the  full  integration  of  the  Test  Bed 
databases.  Reliable  implementation  of  the  distributed  updates 
require  services  developed  previously.  The  Guaranteed  Delivery 
service  developed  under  the  6201M  contract  ensure  that 
Transactions  are  not  lost  nor  duplicated.  The  serialisation 
logic  and  conflict  analysis  loglo  developed  under  1 ten-1  ensures 
maximum  system  throughput,  repeatability  and  the  absoenoe  of 
dead  looks. 

Item  S  -  Extension  to  IMS.  To  Total:  The  update  and  query 
capabilities  developed  against  the  6201  speoifio  instances  of 
database  managers  are  extended  to  other  database  management 
systems  popular  in  the  US  Aerospaoe  Industry.  IMS  and  TOTAL 
have  been  singled  out  by  the  I CAM  program  office  to  be  of 
significant  Interest  to  the  2201  contractor.  Extension  to 
TOTAL,  a  network  type  database  manager  requires  the  development 
of  a  processor  capable  of  translating  Generio  COBOL  query 
processors  into  COBOL  query  processors  written  with  TOTAL  Data 
Maun i pul at ion  Language.  The  extension  of  the  update  and  query 
capabilities  to  IMS  will  be  significantly  more  complex  since  IMS 
is  a  hierarchical  database  manager.  The  added  complexity  of  the 
implementation  of  the  Test  Bed  Meutral  Data  Manipulation 
Language  on  IMS  stems  from  some  undesirable  properties  of 
hierarchical  database  managers  [CJDATE] .  These  properties 
result  from  the  asymmetrical  nature  of  hierarchies. 

Get  next  operations  must  be  qualified  by  an  ‘‘under*  clause 
to  specify  context,  and  additional  information  must  be  provided 
to  solve  problems  introduced  by  the  hierarchical  data 
structures.  In  this  context,  many  to  many  relationships  are 
problematic.  The  hierarchical  database  has  in  addition  the 
following,  well  documented,  anomalies: 

a.  Insertion:  It  is  not  possible  to  insert  a  dependent 
record  if  the  independent  record  has  not  been  defined 
first . 

b.  Deletion:  It  is  not  possible  to  delete  an  independent 
record  without  deleting  all  dependent  records 
associated  with  it. 

c.  Update:  Hierarchical  database  managers  oontain 
redundant  information.  Changes  to  a  dependant  record 
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■ay  li&ve  to  be  duplicated,  leading  to  a  possible 
consistency  problen. 

I  ten  6  -  Extension  to  ISAM  [SATRE]:  Indexed  Sequential 
Access  Method  files  (ISAM)  are  widely  used  in  the  US  Aerospace 
industry  [Program  Office].  This  fact  provides  the  incentive  to 
extend  the  implementation  of  the  MDKL  to  ISAM  files.  The 
difficulties  arising  from  such  an  extension  are  as  follows: 

1.  Lack  of  standardisation 

2.  Access  by  any  key  other  than  the  primary  key  (index) 
are  clumpsy 

5.  Efficiency  is  function  of  the  Activity  in  the  database. 
Mone  the  less,  it  is  believed  that  the  MDML  of  the 
6201 M  Test  Bed  can  be  implemented  against  ISAM  files. 

Item  7  -  Performance  Optimisation:  The  6201M 
Implementation  of  the  Test  Bed  provides  tactical  optimisation  of 
the  data  queries.  The  acoess  paths  followed  to  retrieve  V 
update  data  at  the  Conceptual  and  Internal  levels  are  fixed. 

Data  Aggregation  is  optimised  upon  the  volume  and  location  of 
the  data  retrieved.  This  optimisation  step  is  necessary  but  not 
sufficient.  Further  improvements  in  performance  can  be  achieved 
by  optimising  the  access  paths  followed  to  retrieve  or  update 
data.  Determination  of  the  optimum  path  to  retrieve  data  can  be 
done  via  heuristics  graph  search  techniques  described  in  the 
literature  of  Artificial  Intelligence  [MILS].  Optimisation  of 
the  access  paths  would  be  followed  by  the  optimisation  of  the 
query  aggregation  schedule,  as  done  in  the  6201  Test  Bed. 

Item  8  -  Data  Redundancy:  The  management  of  data 
redundancy  is  one  of  the  most  challenging  problems  of 
distributed  data  processing.  Data  redundancy  has  some  benefits 
on  system  availability,  and  data  query  response  time  but  has 
terrible  siole  effects  on  data  integrity  and  system  overhead  in 
the  update  environment.  The  6201M  Test  Bed  does  not  address  the 
issue  of  data  redundancy.  However,  data  redundancy  must  be  dealt 
with  since  data  redundancy  may  be  imposed  on  the  CDM 
Administrator  by  the  very  structure  of  the  databases  already  in 
existence . 

Furthermore,  the  systematic  elimination  of  all  redundancy 
may  prove  to  be  prohibitively  expensive  when  considering  the 
conversion  cost  of  existing  application  programs.  This,  in 
addition,  run6  contrary  to  the  very  purpose  of  the  Test  Bed. 
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Data  redundancy  Bust  be  decor i bed  In  the  CDM  and  rules  nust 
be  derived  for  the  selection  of  the  location  of  target  data 
under  the  query  and  update  servioes  environments .  System 
ensuring  the  quick  convergence  of  redundant  oopies  of  the  data 
must  be  devised  and  implemented. 

Item  0  -  Natural  Language  Query:  Natural  Language 
Translators  are  coming  of  age,  and  are  capable  of  bridging  the 
gap  between  the  English  language  and  the  formal  -  albeit  user 
unfriendly  -  Relational  Calculus.  Natural  Language  Translators 
thus  make  the  Test  Bed  Query  capability  available  to  a  user  not 
trained  in  Relational  Caloulus.  The  techniques  used  to 
construct  Natural  Language  Processors  have  been  described  in  the 
literature  [PTGLO] .  Natural  Language  Processors  perform  lexical 
analysis,  syntax  analysis,  semantic  and  discourse  analysis  of 
the  query.  Ambiguities  of  the  natural  language  are  flagged  and 
the  Relational  Calculus  equivalent  of  the  Natural  Language  is 
oontructed.  The  Ad-hoc  query  capabilities  described  in  Item-S 
is  a  building  block  to  the  natural  language  based  ad-hoc  query 
capabilities. 

Item  10  -  Intelligent  Retrieval  From  databases: 

Intelligent  retrieval  from  a  database  involves  deductive 
reasoning  with  the  facts  contained  in  the  database.  The 
understanding  of  the  query  may  be  performed  through  the  Natural 
Language  Processors  described  in  Item-9  and  may  involve 
knowledge  beyond  that  explicitly  represented  in  the  database. 
Common  knowledge  is  typically  omitted,  and  is  however  required 
to  interpret  the  semantics  of  a  query.  The  representation  of 
the  common  knowledge  is  a  state  of  research  problen  [NILS]. 

C.8.4  Test  Bed  Development  Software  Migration  Path 

The  development  of  new  Application  Processes  on  the  Test 
Bed  is  subjeot  to  the  economic  consideration  set  forth  in  the 
section  entitled  "Software  Environment”.  Application  Processes 
specifically  developed  for  the  Test  Bed  reflect  the  concern  for 
acoepted  Software  Engineering  concepts  of  nodularity,  cohesion, 
minimum  coupling,  data,  terminal  and  host  independence  while 
making  maximum  use  of  existing  software  or  non  procedural 
software  to  improve  programming  staff  productivity.  Figure  MP-4 
illustrates  a  likely  migration  path  for  the  Test  Bed  Application 
Process  Development  Software.  The  nonprocedural  data 
manipulation  language,  used  for  query,  and  for  update  purposes, 
has  been  implicitly  described  in  the  section  "Distributed 
database  Management  Migration  Path." 
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I tea  1  -  Fortran  IDNL  Preprocessor:  The  6201M  contract 
developed  a  COBOL  MDML  Preprocessor.  This  preprocessor  is  used 
to  prepass  COBOL  programs  containing  VDML  statements.  It  is 
clear  that  a  FORTRAN  MDML  Preprocessor  must  be  developed 
promptly  since  a  significant  number  of  Application  Processes  are 
written  in  FORTRAN  and  since  conversion  to  COBOL  is  either 
difficult  or  expensive.  The  functionality  of  the  COBOL  MDML  pre 
processor  is  that  of  the  pre  processor  written  under  contract 
6201M. 

Item  2  -  Report  Generator:  Report  Generators  are  an 
example  of  shared  oode  boosting  programmer's  productivity.  Many 
report  generators  exist  today  and  are  commercially  available. 
These  systems,  however,  are  not  directly  useable  in  the 
distributed  database  management  context,  and  need  to  be  modified 
or  improved  to  provide  a  user  friendly  and  economical  way  for 
the  end  user  to  display  and  format  the  information  retrieved 
from  the  Test  Bed. 

Item  3  -  Message  Definition  Syntax:  Coordination  and 
Communication  in  the  Test  Bed  is  performed  via  messages  exhanged 
between  the  various  cooperating  application  processes.  Data  and 
System  Integrity  is  enhanced  by  checking  messages  which  have 
predefined  syntax.  The  Message  Definition  Syntax  allows  the 
definition  of  messages  which  can  be  easily  checked  by  the 
Network  Transaction  Manager.  The  Syntax  could  be  defined,  for 
variable  format  messages,  by  transmitting  the  message  format 
along  with  the  message. 

Item  4  -  Distributed  Macros:  Further  programmer 
productivity  can  be  reaped  by  defining  and  implementing  Macros 
for  functions  frequently  invoked.  In  the  context  of  the  Test 
Bed,  those  Macros  would  perform  distributed  data  retrievals  and 
updates,  and  could  be  invoked  by  messages. 

These  Macros  implement  operations  of  particular  importance 
to  the  manufacturing  user.  A  Macro  allowing  the  user  to  issue  a 
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tool  from  the  tool  orlb  to  a  particular  workstation  is  an 
exaaple  of  such  a  Macro. 

I ten  5  -  Data  Effectivity:  Data  Effectivity  is  of 
particular  interest  to  the  Manufacturing  user.  The 
iaplenentation  of  data  effectivity  checks ,  supported  by  systen 
software,  would  facilitate  the  use  of  effectivity  data  when  it 
has  been  defined. 

Item  6  -  Software  Version  Enforcement :  Application 
Processes  and  System  Servioes  are  highly  dependent  upon  the 
version  of  the  CDM  data  used  for  their  compilation.  Enforcement 
of  a  match  between  Application  Process  version  and  corresponding 
CDM  data  version  improves  the  reliability  of  the  Test  Bed  by 
ensuring  that  Application  Processes  are  using  proper  CDM  data. 

Item  7  -  Shared  Code:  The  Test  Bed  integrates  many 
applications  and  it  is  used  by  many  users  who  may  not  have  the 
opportunity  to  communicate  with  one  another.  In  such  an 
environment  the  likelihood  that  users  develop  similar 
application  processes  is  very  high.  To  reduce  the  software 
development  duplication,  a  method  needs  to  be  devised  (Group 
Technology  Classification)  to  allow  for  the  systematic  sharing 
of  existing  application  processes  among  users. 

Item  8  -  Data  Types:  Abstract  data  types  have  a 
significant  positive  impact  on  software  reliability.  Abstract 
data  types  facilitate  the  manipulation  of  the  data  by  defining 
allowable  operations  and  by  preventing  the  user  from  gaining 
access  to  the  internal  representation  of  the  data.  Capsules 
[SOFT]  are  defined  to  encapsulate  both  the  internal 
representation  and  the  operation  to  be  performed  on  the  data. 

The  Capsules  serve  as  non  procedural  building  blocks  to  the 
Application  Programmers,  and  further  improve  productivity  by 
relieving  the  Application  Programmer  from  knowing  the  details  of 
the  internal  data  structure  and  associated  constraints.  System 
services  must  prevent  direct  access  to  the  data  for  data  types 
to  be  of  maximum  utility. 

C.8.5  Graphics 

The  need  for  retrieving  and  for  transmitting  graphic  data 
files  will  arise  as  the  Test  Bed  moves  into  the  manufacturing 
environment.  Present  and  future  graphic  CAD/CAM  systems  are 
turn  key  systems,  which  will  be  progressively  brought  under  the 
Test  Bed.  The  following  developments  will  enhance  the  use  of 
graphic  data  on  the  Test  Bed. 
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1.  Virtual  Terminal  Graphic  Capabilities 

Line  graphic  capabilities  on  the  Virtural  Terminal 
will  facilitate  the  display  (but  not  editing)  of 
graphic  data  prepared  on  the  turn  key  graphic 
systems.  This  capability  allows  the  display  of 
graphic  data  in  the  shop  without  requiring  special 
hardware,  as  well  as  the  display  of  line  graphics 
generated  by  other  Test  Bed  application  processes. 

2.  Integration  of  Graphic  Databases 

The  graphic  databases  of  turn  key  systems  will  be 
progressively  integrated  as  documentation  of  existing 
graphic  database  structures  and  direct  LAM  interfaces 
become  available.  Conversion  to  a  neutral  format 
(IGES)  will  further  facilitate  the  integration  of 
graphic  data. 

C.8.6  Control  Architecture  Migration  Path 

The  Control  Architecture  Migration  Path  shown  on  Figure 
C-12  facilitates  the  implementation  of  new  application  processes 
on  the  Test  Bed  by  providing  more  elaborate  methodology  and 
tools  as  time  progresses. 

1.  Test  Bed  Administrator  Guide 

A  guide  is  provided  to  the  Test  Bed  administrator  to 

assist  him  or  her  in  the  task  of  defining: 

a.  Users  who  should  have  access  to  the  Test  Bed 

b.  What  information  should  be  provided  to  these  users 

c.  Which  application  processes  are  required 

d.  Which  screens,  etc.  are  required 

e.  How  to  audit  system  and  data  usage  made  by  the 
users 

f.  How  to  use  the  Test  Bed  Data  Dictionary 

2.  Programmer's  Guide 
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A  guide  is  provided  to  the  application  programmer  to 
assist  in  the  design  and  ooding  of  application 
programs  on  the  Test  Bed.  The  programmer's  guide 
describes: 

a.  Meutral  Data  Definition  Language 

b.  neutral  Data  Manipulation  Language 

c.  Services  provided  by  the  Test  Bed 

d.  User  Interface  services 

e.  Prepassing  and  compilation  procedures 

f .  Test  Bed  operating  principles 

g.  Test  Bed  error  messages 

3.  CDM  Administrator  Guide 

The  CDM  Administrator  Guide  assists  the  CDM 
Administrator  in  creating  the  schemas  (external, 
internal,  conceptual)  required  to  integrate  new 
applications  and  databases  on  the  Test  Bed.  The  CDM 
Administrator  guide  describes: 

a.  IDEF1  methodology  and  its  extension 

b.  How  to  create  an  Internal  schema  for  an  existing 
database 

c.  How  to  create  and  augment  the  Conceptual  schema 

d.  How  to  create  an  External  schema 

e.  How  to  define  the  mappings  between  the  schemas 

f.  How  to  store,  edit,  schemas  on  the  CDM 

g.  How  to  use  the  CDM  data  dictionary 

4.  User's  Guide 

The  user  guide  describes  the  operations  of  the  Test  Bed 
to  the  end  user.  This  guide  describes: 
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a. 

The  User  Interface  services,  froa  the  end  U6er 
point  of  view 

> 

b. 

Error  aes sages 

c. 

High  level  explanation  of  the  Test  Bed  operating 
principles 

5.  Foras  Editor 


The  foras  editor  is  a  6201M  shortfall.  This  total 
should  be  developed  rapidly  to  give  the  user  the 
flexibility  required  to  define  foras  graphically  (by 
aoving  strings  on  the  CRT)  and  textual ly. 

6.  CDM  Versioning 

Versioning  of  the  CDM  is  a  620 1M  shortfall.  This 
iaportant  service  aust  be  provided,  since  it  will  allow 
aaking  changes  to  the  CDM  without  having  to  preprocess 
and  recoapile  all  application  processes.  The 
granularity  of  CDM  Version  nuabering  systea  aust  allow 
to  single  out  those  application  processes  affected  by  a 
change  to  the  CDM  data.  It  is  noted  that  soae  changes 
(passwords  for  exaaple)  have  no  iapact  on  the 
recoapi lation  of  application  processes. 

7.  On  Line  Data  Dictionary 

An  on  line  data  dictionary  is  needed  to  assist  the  CDM 
Adainistrator  in  the  burdensone  task  of  keeping  track 
of  data  definition,  an d  semantics .  The  data  dictionary 
is  updated  autoaatically  when  changes  are  made  to  the 
CDM. 

8.  Application  Process  Interference 

Application  process  classes  need  to  be  defined 
autoaatically  by  the  Test  Bed.  An  application  process 
class  aay  contain  one  or  nore  application  processes, 
provided  that  they  are  using  the  saae  logical  read  set 
and  write  set  of  data  (SDD-1).  The  grouping  of 
application  processes  into  classes  allow  significant 
iaproveaents  in  systea  perforaance.  This  assignaent 
aust  be  error  free  since  conflict  and  inconsistencies 
aay  result  froa  the  interleaved  processing  of 
application  processes  of  the  sane  class.  Autonation  of 
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application  process  class  definition  is  thought  to  be 
aore  effective  and  reliable  than  annual  definition. 

9.  Coaputer  Assisted  IDEF1 

The  methodology  developed  for  the  integration  of 
existing  databases  calls  for  the  development  of 
normalised  IDEF1  data  models  (DAGOM).  A  coaputer 
assisted  XDKF1  model  building  tool  will  make  this 
prooess  more  productive,  less  error  prone.  It  will 
provide  the  hand  holding  required  for  transitioning  the 
Test  Bed  away  from  its  developers.  The  IDEP1  model 
builder  cannot  be  fully  automated,  but  it  can  be  made 
interactive  and  exhaustive.  This  tool  should  accept 
input  from  the  model  builder,  from  IDE71  models  already 
stored  in  the  GDM  or  from  the  schemas  of  existing 
databases  already  defined. 

10.  Coaputer  Assisted  Schema  Mapper 

The  task  of  mapping  schemas  is  thought  to  be  tedious 
and  is  a  good  candidate  for  ooaputer  assistance. 

Schema  mapping  cannot  be  automated,  for  it  requires  too 
much  common  knowledge  about  data  semantics.  Schema 
mapping  can.  however,  be  made  highly  interactive  and 
the  coaputer  be  of  significant  assistance  in  checking 
completeness  and  self  consistency  of  the  mappings. 

1 1 .  Resource  Management 

The  resource  management  capabilities  provided  for  the 
6201M  Test  Bed  are  satisfactory  for  the  laboratory  or 
experimental  phase  of  the  life  of  the  Test  Bed. 

However,  as  the  Test  Bed  expands  to  full  production 
status,  improved  resource  management  capabilities  must 
be  provided  for  budgetary  control . 

12.  Data  Security 

The  ad-hoc  environment  poses  added  data  security 
problems.  In  this  environment,  data  security  cannot  be 
enforoed  via  anoess  control .  More  granular  data 
security  information  must  be  provided,  to  allow 
distinguishing  between  valid  and  invalid  data  usages  of 
a  legitimate  user.  Subdividing  users  into  security 
levels  is  a  convenient  way  of  enforcing  direct  data 
security  among  legitimate  users  of  a  database. 
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Enforcement  of  this  additional  soourity  constraint  snst 
he  provided  in  the  Test  Bed  via  shared  systea  services. 

The  need  for  data  encryption  nay  arise  as  aore 
sensitive  data  (ooaaeroial  or  ailltary)  is  brought 
under  the  Test  Bed.  Approved  encryption  algor ithas 
(DBS)  aay  be  used  on  the  Test  Bed,  and  be  lapleaented 
on  aessage  handler  processors  and  workstations. 

C.O  Prioritised  List  of  Developaent  Activities 

The  following  is  a  prioritised  list  of  developaent 
activities  required  to  transition  the  Test  Bed  froa  its  state  of 
ooapletion  at  the  end  of  the  6201M  oontraot  to  full  production 
status.  The  developaent  activities  called  are  those  described 
in  Section  8. 

PHASE  1:  DEMONSTRATION  OF  BASIC  CAPABILITIES 

1.  Full  Query  Capabilities: 

a.  Serialisation  and  oonflict  analysis 

1.  Tine  stanp  processing  or  other  oonflict 
avoiding  technique 

2.  Transaction  class  processing 

b.  Restart /Recovery 

c.  Binary  File  Transfer 

d.  Fortran  NDKL  Pre  processor 

2.  Ad-Hoc  Query  Capabilities 

a.  Ad-Hoc  Query  (PREDICATE) 

3.  Distributed  Update  Capabilities 
a.  Distributed  Updates 

PHASE  2:  DEVELOP.  AUTOMATE  INTEGRATION  METHODOLOGY 

a .  Data  Redundancy 

b.  Coaputer  assisted  IDEF-1 

c.  Coaputer  assisted  scheaa  sapper 

d.  CDM  Versioning 

e.  CDM  Utilities 

f.  On  line  Data  Dictionary 

g.  Test  Bed  Adainistrator  Guide 

h.  Programmer's  Guide 
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&.  CDM  Administrator  Guide 
j .  User ' s  Guide 

PHASE  5:  PREPARE  FOR  NIGRATIOH  TO  MANUFACTURING 
EHVIROMMEHT 

a.  Extension  to  IMS  and  TOTAL 

b.  Extension  to  ISAM 
o.  Data  effect ivity 

d.  Application  process  interference  classification 

e.  Performance  optimisation 

1.  Retrieval  optimisation  -  conceptual  level 

2.  Retrieval  optimisation  -  Internal  level 

f.  Virtual  terminal  line  graphic  capabilities 

g .  Resource  management 

h.  Data  security 

i.  Workstations 

j.  LAM  configuration  unit  9  self  troubleshooting 
PHASE  4:  DEVELOP  TOOLS  TO  IMPLEMEMT  HEW  APPLICATIONS 

a.  Forms  editor 

b.  Report  generator 

c.  Message  definition  syntax 

d.  Distributed  manufacturing  macros 

PHASE  5:  IMPROVE  TEST  BED  PERFORMANCE 

a.  Direct  LAN  Interfaces 

1.  Procure,  install  hardware 

2.  Modify  COMM  software 

b.  Message  handler  processors 

1.  Procure,  install  hardware 

2.  Modify  NTM  software 

c.  Backend  processors 

1.  Procure,  install  hardware 

2.  Modify  query  generators 

d .  Hardware  redundancy 

PHASE  6:  GRAPHICS  CAPABILITIES 

a.  Graphic/LAN  direct  interfaces 

b.  Integration  of  graphic  databases 

PHASE  7:  ADVANCED  CAPABILITIES 


a.  Shared  code  classification 
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b. 

Abstract  data  types  1 

c. 

Natural  Language  Query  Processor  1 

d. 

Intelligent  database  retrieval  1 
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